Определение типовых ошибок конфигурации stp

ASR типичные проблемы серии 9000 с протоколами STP

Параметры загрузки

Об этом переводе

Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.

Содержание

Введение

Этот документ описывает типичные проблемы, которые возникают при интеграции текущих пользовательских сетей со связующим деревом уровня 2 (L2) на коммутаторах Cisco IOS® с маршрутизаторами с агрегацией сервисов (ASR) серии Cisco 9000, которые работают под управлением Cisco IOS XR.

Проблема — несоответствие идентификаторов VLAN портов (PVID)

Коммутаторы Cisco IOS, которые работают на протоколе Per VLAN Spanning Tree Plus (PVST+), блокируют порты коммутатора, когда они принимают a блок данных протокола моста (BPDU) с несовместимым PVID. Эта проблема возникает, когда для устройства между коммутаторами меняются или транслируются метки IEEE 802.1Q на PVST + BPDU.

Если ASR 9000 предоставляет двухточечную или многоточечную услугу L2VPN между коммутаторами, которая использует PVST+ и перезаписывает метки VLAN, эти сообщения в системном журнале могут отображаться на коммутаторах на базе Cisco IOS:

Эта проблема возникает из-за метки PVID, которая включается с PVST + BPDU. Эта метка предназначена для обнаружения неверных конфигураций и предотвращения случайных петель. Вместе с тем в данном сценарии это приводит к блокировке всех концов и не позволяет проводить трафик.

Здесь представлена конфигурация ASR серии 9000 (a9k1):

Решение

Для предотвращения этой проблемы можно заблокировать PVST + BPDU. Если между коммутаторами есть доступные резервированные соединения, это действие отключает связующее дерево и может привести к образованию петель.

Внимание. : Будьте осторожны, когда блокируете BPDU, и отключите связующее дерево.

Фильтр BPDU на коммутаторах

BPDU заблокированы с функцией фильтра BPDU на коммутаторах. Фильтр BPDU блокирует BPDU в обоих направлениях, что приводит к отключению связующего дерева на порту. Фильтр BPDU предотвращает входящий и исходящий BPDU. При включении фильтрации BPDU на интерфейсе создается такая же ситуация, как и при отключении связующего дерева на нем, что может привести к образованию петель в связующем дереве.

На коммутаторах 1 и 2 включите фильтры BPDU с помощью команды:

Блочный PVST + BPDU на ASR 9000

Эта проблема не возникает, если настроить ASR9000 на отбрасывание PVST + BPDU. Это делается с использованием списка доступа к сервисам Ethernet уровня L2 с целью запрета пакетов, которые предназначены для отправки на MAC-адрес PVST+ BPDU.

PVST + BPDU для сети (не VLAN) 1 (несобственной) VLAN передаются на PVST + MAC-адрес (также называемый MAC-адресом протокола общего связующего дерева [SSTP], 0100.0ccc.cccd) и маркируются соответствующей меткой VLAN IEEE 802.1Q.

Этот список контроля доступа (ACL) может использоваться для блокирования PVST + BPDU:

Примените ACL к интерфейсу, настроенному как l2transport:

Проблема — порты коммутатора спонтанно переключаются между блокированием и пересылкой при использовании нескольких разновидностей протокола связующего дерева (STP) через ASR 9000

ASR9000 не создает связующего дерева по умолчанию, как и большинство коммутаторов Cisco IOS. В модели виртуального канала Ethernet (EVC) пакет BPDU является просто еще одним многоадресным пакетом L2. Типичной проблемой является несоответствие связующего дерева из-за нескольких разновидностей STP, которые работают на домене моста ASR 9000. Это проявляется несколькими различными способами.

Рассмотрим такую простую топологию:

Предположите, что коммутатор 1 использует множественное связующее дерево (MST), а коммутатор 2 использует PVST+. Если a9k1 не использует ни одной разновидности связующего дерева, коммутатор 1 считает его граничным портом. Коммутатор 1 возвращается к режиму PVST для сетей VLAN, которых нет в общем экземпляре связующего дерева 0 (CST0). Если это и есть необходимая модель, необходимо ознакомиться со взаимодействием MST и PVST, описанным в документе Описание множественного протокола связующего дерева (802.1s).

Теперь предположим, что используется MST на коммутаторе 1 и на интерфейсе a9k1, который приводит к коммутатору 1, но при этом используется PVST + на коммутаторе 2. PVST + BPDU проходят через домен моста и доходят до коммутатора 1. Затем коммутатор 1 распознает как пакеты BPDU MST от a9k1, так и PVST + BPDU от коммутатора 2, и это приводит к тому, что связующее дерево на порту коммутатора 1 постоянно переключается с блокирования на неблокирование, что, в свою очередь, приводит к потере трафика.

Коммутатор 1 предоставляет системные журналы:

Результат выполнения команды show spanning-tree interface показывает, что этот результат постоянно меняются на устройстве Cisco IOS коммутатора 1:

Решение

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

Проблема — порты связующего дерева заблокированы вследствие обнаружения петли

Когда коммутатор получает пакет BPDU связующего дерева, который отправляется на том же интерфейсе, коммутатор блокирует эту VLAN вследствие образования петли. Это типичная проблема, возникающая тогда, когда коммутатор с магистральным портом подключен к маршрутизатору ASR 9000, который предоставляет многоточечные сервисы L2, а ASR 9000 не перезаписывает метки VLAN в интерфейсах l2transport на том же домене моста.

Рассмотрим ту же простую топологию, которая была показана ранее. Вместе с тем теперь из-за схемы работы a9k1 несколько сетей VLAN от одного и того же магистрального интерфейса коммутатора, объединяются в одном домене моста.

Это конфигурация a9k1:

Она объединяет сети VLAN (2-4) в один домен моста на a9k1.

Модель ASR 9000 EVC не перезаписывает ни метки, ни почтовый протокол по умолчанию. Данные PVST + BPDU для VLAN2 приходят на интерфейс gig 0/1/0/31.2 и пересылаются обратно на gig 0/1/0/31.3 и gig 0/1/0/31.4. Так как конфигурация не является перезаписью действия почтового протокола входящего потока, BPDU возвращается неизменным. Коммутатор распознает эту ситуацию, так как получает обратно свой собственный пакет BPDU, и блокирует эту сеть VLAN из-за петли.

Команда show spanning-tree interface отображает заблокированную сеть VLAN:

Решение

Эта проблема устраняется посредством использования команды ethernet egress-filter strict в интерфейсах ASR 9000 l2transport.

Это не схема работы не является рекомендуемой. Вместе с тем, если это действительно необходимая схема работы, можно использовать это решение, чтобы коммутатор не получал пакет BPDU, который отправляется обратно в том же интерфейсе.

Можно использовать команду ethernet egress-filter strict в интерфейсах a9k1 l2transport или на глобальном уровне. Это пример в интерфейсе:

Команда ethernet egress-filter strict включает строгую фильтрацию точки потока Ethernet (EFP) для исходящего потока в интерфейсе. Только пакеты, которые проходят фильтр EFP входящего потока в интерфейсе, отправляются из этого интерфейса. Остальные пакеты отбрасываются в фильтре исходящего потока. Это означает, что если пакет, который является исходящим, не соответствует метке encapsulation dot1q, заданной в интерфейсе, то пакет не передается.

Источник

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Траблшутинг STP (Spanning tree protocol)

Часть.2 4 кейса по проблемам с STP

Предыдущая статья этого цикла:

Онлайн курс по Кибербезопасности

Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии

Следующая статья этого цикла:

Case #1

На рисунке представлена топология, состоящая из трех коммутаторов, и между коммутаторами у нас есть два канала связи для резервирования. Коммутатор А был выбран в качестве корневого моста для VLAN 1. Когда вы имеете дело со связующим деревом, лучше всего нарисовать небольшую схему сети и записать роли интерфейса для каждого коммутатора (назначенного, не назначенного/альтернативного или заблокированного). Обратите внимание, что одним из каналов связи между коммутатором A и коммутатором C является интерфейс Ethernet (10 Мбит). Все остальные каналы — это FastEthernet.

Мы используем команду show spanning-tree для проверки ролей интерфейса для коммутатора A и коммутатора C. Вы видите, коммутатор C выбрал свой интерфейс Ethernet 0/13 как корневой порт, а интерфейс FastEthernet 0/14 выбран в качестве альтернативного порта. Это не очень хорошая идея. Это означает, что мы будем отправлять весь трафик вниз по линии 10 Мбит, в то время как 100 Мбит не используется вообще. Когда коммутатор должен выбрать корневой порт он выберет его следующим образом:

Почему коммутатор выбрал интерфейс Ethernet 0/13?

Мы видим, что интерфейс Ethernet 0/13 и FastEthernet0/14 имеют одинаковую стоимость. Затем коммутатор С выберет самый низкий номер интерфейса, который является interface Ethernet 0/13.

После проверки конфигурации интерфейса, видно, что кто-то изменил стоимость интерфейса на 19 (по умолчанию для интерфейсов FastEthernet).

Уберем настройки команды cost.

После того, как мы убрали настройки команды cost, видно, что состояние порта изменилось. FastEthernet 0/14 теперь является корневым портом, а стоимость интерфейса Ethernet 0/13 равна 100 (это значение по умолчанию для интерфейсов Ethernet). Задача решена!

Извлеченный урок: убедитесь, что интерфейс, которым вы хотите сделать в качестве корневого порта, имеет наименьшую стоимость пути.

Case #2

Итак, новый сценарий. Все интерфейсы равны (FastEthernet). Коммутатор A является корневым мостом для VLAN 10, и после проверки ролей интерфейса мы находим следующее:

Хм, интересно. Коммутатор A является корневым мостом, а FastEthernet 0/17 был выбран в качестве резервного порта. Это то, что вы видите каждый день. Коммутатор B выбрал корневой порт, а все остальные интерфейсы являются альтернативными портами. Мы ничего не видим на коммутаторе С.

Мы видим, что Коммутатор A и Коммутатор B используют связующее дерево для VLAN 10. Коммутатор C, однако, не использует связующее дерево для VLAN 10. В чем может быть проблема?

Конечно, неплохо проверить, работают ли интерфейсы на коммутаторе C или нет (но, конечно, это то, что вы уже изучили и сделали в первой статье).

Интерфейсы выглядят хорошо. VLAN 10 активна на всех интерфейсах коммутатора C. Это означает, что остовное дерево должно быть активным для VLAN 10.

Давайте еще раз посмотрим на это сообщение. Это говорит о том, что остовное дерево для VLAN 10 не существует. Есть две причины, по которым можно увидеть это сообщение:

Мы подтвердили, что VLAN 10 активна на всех интерфейсах коммутатора C, поэтому, может быть, связующее дерево было отключено глобально? SwitchC(config)#spanning-tree vlan 10

Извлеченный урок: проверьте, включено ли связующее дерево.

Case #3

Давайте продолжим по другому сценарию! Та же топология. наш клиент жалуется на плохую работу. Начнем с проверки ролей интерфейсов:

Так почему же остовное дерево провалилось здесь? Здесь важно помнить, что связующему дереву требуются блоки BPDU, передаваемые между коммутаторами для создания топологии без петель. BPDU могут быть отфильтрованы из-за MAC access-lists, VLAN access-maps или из-за spanning-tree toolkit?

Ни на одном из коммутаторов нет VLAN access maps.

Нет списков доступа.

Нет port security. как насчет команд, связанных с остовным деревом?

Вот что-то есть!Фильтр BPDU был включен на интерфейсах FastEthernet 0/16 и 0/17 коммутатора B. Из-за этого коммутатор C не получает BPDU от коммутатора B.

Удалим настройки фильтра BPDU.

Теперь вы видите, что FastEthernet 0/16 и 0/17 являются альтернативными портами и блокируют трафик. Наша топология теперь без петель. проблема решена!

Извлеченный урок: убедитесь, что блоки BPDU не заблокированы и не отфильтрованы между коммутаторами.

Case #4

Новая топология. Коммутатор A был выбран в качестве корневого моста для VLAN 10. Все интерфейсы являются FastEthernet каналами.

После использования команды show spanning-tree vlan 10 вот, что мы видим. Все интерфейсы одинаковы, но по какой-то причине коммутатор B решил выбрать FastEthernet 0/16 в качестве корневого порта. Разве вы не согласны с тем, что FastEthernet 0/13 должен быть корневым портом? Стоимость доступа к корневому мосту ниже, чем у FastEthernet 0/16.

Есть несколько вещей, которые мы могли бы проверить, чтобы увидеть, что происходит:

Во-первых, всегда полезно проверить, активно ли связующее дерево для определенной VLAN. Можно отключить spanning-tree с помощью команды no spanning-tree vlan X. В этом сценарии связующее дерево активно для VLAN 10, потому что мы можем видеть на FastEthernet 0/16 и 0/17.

Мы знаем, что остовное дерево активно глобально для VLAN 10, но это не значит, что оно активно на всех интерфейсах. Мы можем использовать команду show interfaces switchport, чтобы проверить, работает ли VLAN 10 на интерфейсе FastEthernet 0/13 и 0/14. Это отобразит нам некоторую интересную информацию. Вы видите, что эти интерфейсы оказались в режиме доступа, и они находятся в VLAN 1.

Давайте изменим режим интерфейсов на магистральный, чтобы трафик VLAN 10 мог проходить через эти интерфейсы.

Ну вот, теперь все намного лучше выглядит. Трафик VLAN 10 теперь передается по интерфейсу FastEthernet 0/13 и 0/14, и вы видите, что интерфейс FastEthernet 0/13 теперь выбран в качестве корневого порта. Задача решена!

Извлеченный урок: убедитесь, что VLAN активна на интерфейсе, прежде чем рассматривать проблемы связующего дерева.

Полный курс по Сетевым Технологиям

В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer

Источник

Принцип работы протокола STP

Причина создания STP

Причиной создания протокола STP стало возникновение петель на коммутаторах. Что такое петля? Определение петли звучит так:

Петля коммутации (Bridging loop, Switching loop) — состояние в сети, при котором происходит бесконечная пересылка фреймов между коммутаторами, подключенными в один и тот же сегмент сети.

Из определения становится ясно, что возникновение петли создает большие проблемы — ведет к перегрузке свитчей и неработоспособности данного сегмента сети. Как возникает петля? На картинке ниже приведена топология, при которой будет возникать петля при отсутствии каких-либо защитных механизмов:

Возникновение петли при следующих условиях:

1. Какой-либо из хостов посылает бродкаст фрейм:

2. Также петля может образоваться и без отправки бродкаст фрейма.

Основы STP

Принцип работы данного протокола построен на том, что все избыточные каналы между коммутаторами логически блокируются и трафик через них не передается. Для построения топологии без избыточных каналов строится дерево (математический граф). Чтобы построить такое дерево вначале необходимо определить корень дерева, из которого и будет строиться граф. Поэтому первым шагом протокола STP является определение корневого коммутатора (Root Switch). Для определения Root Switch-a, коммутаторы обмениваются сообщениями BPDU. В общем, протокол STP использует два типа сообщений: BPDU — содержит информацию о коммутаторах и TCN — уведомляет о изменении топологии. Рассмотрим BPDU более детально. Про TCN более подробно поговорим ниже. При включении STP на коммутаторах, коммутаторы начинают рассылать BPDU сообщения. В данных сообщениях содержится следующая информация:

Фрейм BPDU имеет следующие поля:

Вот вывод информации о Bridge ID с коммутатора Switch1 из первой картинки. Priority — 32769 ( по умолчанию 32768 + Vlan Id), MAC-адреса — Address 5000.0001.0000:

Представим картину, коммутаторы только включились и теперь начинают строить топологию без петель. Как только коммутаторы загрузились, они приступают к рассылке BPDU, где информируют всех, что они являются корнем дерева. В BPDU в качестве Root Bridge ID, коммутаторы указывают собственный Bridge ID. Например, Switch1 отправляет BPDU коммутатору Switch3, а Switch3 отправляет к Switch1. BPDU от Switch1 к Switch3:

BPDU от Switch3 к Switch1:

Как видим из Root Identifier, оба коммутотара друг другу сообщают, что именно он является Root коммутатором.

Выбор корневого коммутатора

Пока топология STP не построена, обычный трафик не передается из-за специальных состояний портов, о которых будет сказано ниже. Итак, Switch3 получается BPDU от Switch1 и изучает данное сообщение. Switch3 смотрит в поле Root Bridge ID и видит, что там указан другой Root Bridge ID, чем в том сообщении, которое отправил сам Switch3. Он сравнивает Root Bridge ID в данном сообщении со своим Root Bridge ID и видит, что хоть Priority одинаковые, но MAC-адрес данного коммутатора (Switch1) лучше (меньше), чем у него. Поэтому Switch3 принимает Root Bridge ID от Switch1 и перестает отправлять свои BPDU, а только слушает BPDU от Switch1. Порт, на котором был получен наилучший BPDU становится Root Port-ом. Switch1 также получив BPDU от Switch3, проводит сравнение, но в этом случае поведение Switch1 не меняется, так как полученный BPDU содержит худший Root Bridge ID, чем у Switch1. Таким образом, между Switch1 и Switch3 был определен корневой коммутатор. По аналогичной схеме происходит выбор корневого коммутатора между Switch1 и Switch2. Порты Gi0/0 на Switch2 и Switch3 становятся Root Port — порт, который ведет к корневому коммутатору. Через данный порт коммутаторы Switch2 и Switch3 принимают BPDU от Root Bridge. Теперь разберемся, что произойдет с каналом между Switch2 и Switch3.

Блокирование избыточных каналов

Как мы видим из топологии, канал между Switch2 и Switch3 должен быть заблокирован для предотвращения образования петель. Как STP справляется с этим?

После того, как выбран Root Bridge, Switch2 и Switch3 перестают отправлять BPDU через Root Port-ы, но BPDU, полученные от Root Bridge, они пересылают через все свои остальные активные порты, при этом изменив в данных BPDU только следующие поля:

А Switch3 от Switch2 получает такой BPDU:

После обмена такими BPDU, Switch2 и Switch3 понимают, что топология избыточна. Почему коммутаторы понимают, что топология избыточна? И Switch2, и Switch3 в своих BPDU сообщают об одном и том же Root Bridge. Это означает, что к Root Bridge, относительно Switch3, существует два пути — через Switch1 и Switch2, а это и есть та самая избыточность против которой мы боремся. Также и для Switch2 два пути — через Switch1 и Switch3. Чтоб избавиться от этой избыточности
необходимо заблокировать канал между Switch3 и Switch2. Как это происходит?

Выбор на каком коммутатоторе заблокировать порт происходит по следующей схеме:

Здесь как оказалось заблокируется порт Gi 0/1 на коммутаторе Sw2. В данном голосовании определяющим становится Root Path Cost. Вернемся к нашей топологии. Так как путь до Root Bridge одинаковый, то в данном выборе побеждает Switch2, так как его priority равны, сравниваются Bridge ID. У Switch2 — 50:00:00:02:00:00, у Switch3 — 50:00:00:03:00:00. У Switch2 MAC-адрес лушче (меньше). После того, как выбор сделан, Switch3 перестает переслать какие-либо пакеты через данный порт — Gi1/0, в том числе и BPDU, а только слушает BPDU от Switch2. Данное состояние порта в STP называется Blocking(BLK). Порт Gi1/0 на Switch2 работает в штатном режиме и пересылает различные пакеты при необходимости, но Switch3 их сразу отбрасывает, слушая только BPDU. Таким образом, на данном примере мы построили топологию без избыточных каналов. Единственный избыточный канал между Switch2 и Switch3 был заблокирован при помощи перевода порта Gi1/0 на Switch3 в специальное состояние блокирования — BLK. Теперь более детально разберем механизмы STP.

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

Мы говорили выше, что, например, порт Gi1/0 на Switch3 переходит в специальное состояние блокирования — Blocking. В STP существуют следующие состояния портов:

Blocking — блокирование. В данном состоянии через порт не передаются никакие фреймы. Используются для избежания избыточности топологии.

Listening — прослушивание. Как мы говорили выше, что до того, пока еще не выбран корневой коммутатор, порты находятся в специальном состоянии, где передаются только BPDU, фреймы с данными не передаются и не принимаются в этом случае. Состояние Listening не переходит в следующее даже, если Root Bridge определен. Данное состояние порта длится в течении Forward delay timer, который, по умолчанию, равен 15. Почему всегда надо ждать 15 секунд? Это вызвано осторожностью протокола STP, чтоб случайно не был выбран некорректный Root Bridge. По истечению данного периода, порт переходит в следующее состояние — Learning.

Learning — обучение. В данном состояние порт слушает и отправляет BPDU, но информацию с данными не отправляет. Отличие данного состояния от Listening в том, что фреймы с данными, который приходят на порт изучаются и информация о MAC-адресах заносится в таблицу MAC-адресов коммутатора. Переход в следующее состояние также занимает Forward delay timer.

Forwarding — пересылка. Это обычное состояние порта, в котором отправляются и пакеты BPDU, и фреймы с обычными данными. Таким образом, если мы пройдемся по схеме, когда коммутаторы только загрузились, то получается следующая схема:

Роли портов

Помимо состояний портов, также в STP нужны определить портам их роли. Это делается для того, чтоб на каком порте должен ожидаться BPDU от корневого коммутатора, а через какие порты передавать копии BPDU, полученных от корневого коммутатора. Роли портов следующие:

Root Port — корневой порт коммутатора. При выборе корневого коммутатора также и определяется корневой порт. Это порт через который подключен корневой коммутатор. Например, в нашей топологии порты Gi0/0 на Switch2 и Switch3 являются корневыми портами. Через данные порты Switch2 и Switch3 не отправляют BPDU, а только слушают их от Root Bridge. Возникает вопрос — как выбирается корневой порт? Почему не выбран порт Gi1/0? Через него ведь тоже можно иметь связь с коммутатором? Для определения корневого порта в STP используется метрика, которая указывает в поле BPDU — Root Path Cost (стоимость маршрута до корневого свича). Данная стоимость определяется по скорости канала.

Switch1 в своих BPDU в поле Root Path Cost ставит 0, так как сам является Root Bridge. А вот, когда Switch2, когда отправляет BPDU к Switch3, то изменяет данное поле. Он ставит Root Path Cost равным стоимости канала между собой и Switch1. На картинке BPDU от Switch2 и Switch3 можно увидеть, что в данном поле Root Path Cost равен 4, так как канал между Switch1 и Switch2 равен 1 Gbps. Если количество коммутаторов будет больше, то каждый следующий коммутатор будет суммировать стоимость Root Path Cost. Таблица Root Path Cost.

Designated Port — назначенный порт сегмента. Для каждого сегмента сети должен быть порт, который отвечает за подключение данного сегмента к сети. Условно говоря, под сегментом сети может подразумеваться кабель, который осуществляет подключение данного сегмента. Например, порты Gi0/2 на Switch1, Switch3 подключают отдельные сегменты сети, к которым ведет только данный кабель. Также, например, порты на Root Bridge не могут быть заблокированы и все являются назначенными портами сегмента. После данного пояснения можно дать более строгое определения для назначенных портов:
Designated Port (назначенный) — некорневой порт моста между сегментами сети, принимающий трафик из соответствующего сегмента. В каждом сегменте сети может быть только один назначенный порт. У корневого коммутатора все порты — назначенные.

Также важно заметить, что порт Gi1/0 на Switch2 также является назначенным, несмотря на то, что данный канал связи заблокированным на Switch3. Условно говоря, Switch2 не имеет информации о том, что на другом конце порт заблокирован.

Nondesignated Port — неназначенный порт сегмента. Non-designated Port (неназначенный) — порт, не являющийся корневым, или назначенным. Передача фреймов данных через такой порт запрещена. В нашем примере, порт Gi1/0 является неназначенным.

Disabled Port — порт который находится в выключенном состоянии.

Таймеры и сходимость протокола STP

После того, как STP завершил построение топологии без петель, остается вопрос — Как определять изменения в сети и как реагировать на них? Сообщения BPDU при помощи которых работает STP, рассылаются Root Bridge каждые 2 секунды, по умолчанию. Данный таймер называется Hello Timer. Остальные коммутаторы получив через свой root port данное сообщение пересылают его дальше через все назначенные порты. Выше сказано более подробно какие изменения происходят с BPDU при пересылки его коммутаторов. Если в течении времени, определенным таймером Max Age (по умолчанию — 20 секунд), коммутатор не получил ни одного BPDU от корневого коммутатора, то данное событие трактуется как потеря связи с Root Bridge. Для того, чтобы более корректно описать сходимость протокола необходимо изменить нашу топологию и поставить между коммутаторами хабы. Мы добавили хабы, чтоб при выходе из строя одного из коммутаторов или выхода из строя линка, другие коммутаторы не определяли это по падению линка, а использовали таймеры:

Перед тем, как начать также важно рассказать подробнее о другом типе сообщения STP — TCN. TCN рассылается коммутаторами в случае изменения топологии — как только на каком-либо коммутаторе изменилась топология, например, изменилось состояние интерфейса. TCN отправляется коммутатором только через Root Port. Как только корневой коммутатор получит TCN, он сразу меняет параметр времени хранения MAC-адресов в таблице с 300 секунд до 15 (для чего это делается будет сказано ниже) и в следующем BPDU, Root Switch проставляет флаг — TCA ( Topology Change Acknledgement ), который отправляется коммутатору отправившем TCN для уведовления о том, что TCN был получен. Как только TCN достигает Root Bridge, то он рассылает специальный BPDU, который содержится TCN флаг по всем остальным интерфейсам к другим коммутаторам. На картинке показана структура TCN:

TCN был включен в STP, чтоб некорневые коммутаторы могли уведовлять об изменении в сети. Обычными BPDU они этого делать не могут, так как некорневые коммутаторы не отправляют BPDU. Как можно заметить структура TCN не несет в себе никакой информации о том, что именно и где изменилось, а просто сообщает что где-то что-то изменилось. Теперь перейдем к рассмотрению вопроса о сходимости STP.

Посмотрим, что произойдет если мы отключим интерфейс Gi0/1 на Switch1 и посмотрим при помощи каких механизмов перестроится дерево STP. Switch2 перестанет получать BPDU от Switch1 и не будет получать BPDU от Switch3, так как на Switch3 данный порт заблокирован. У Switch2 уйдет 20 секунд ( Max Age Timer ), чтоб понять потерю связи с Root Bridge. До этого времени, Gi0/0 на Switch2 будет находится в состоянии Forwarding с ролью Root Port. Как только истечет Max Age Timer и Switch2 поймет потерю связи, он будет заново строить дерево STP и как это свойственно STP начнет считать себя Root Bridge. Он отправит новый BPDU, где укажет самого себя в качестве Root Bridge через все активные порты, в том числе и на Switch3. Но таймер Max Age, истекший на Switch2 также истек и на Switch3 для интерфейса Gi1/0. Данный порт уже 20 секунд не получал BPDU и данный порт перейдет в состояние LISTENING и отправит BPDU c указанием в качестве Root Bridge — Switch1. Как только Switch2 примет данный BPDU, он перестанет считать себя Root Bridge и выберет в качестве Root Port — интерфейс Gi1/0. В этот момент Switch2 также отправит TCN через Gi1/0, так как это новый Root Port. Это приведет к тому, что время хранения MAC-адресов на коммутаторах уменьшится с 300 секунд до 15. Но на этом работоспособность сети не восстановится полностью, необходимо подождать пока порт Gi1/0 на Switch3 пройдет состояние Listening, а затем Learning. Это займет время равное двум периодам Forward delay timer — 15 + 15 = 30 секунд. Что мы получаем — при потери связи Switch2 ждет пока истечет таймер Max Age = 20 секунд, заново выберает Root Bridge через другой интерфейс и ждет еще 30 секунд пока ранее заблокированный порт перейдет в состояние Forwarding. Суммарно получаем, что связь между VPC5 и VPC6 прервется на 50 секунд. Как было сказано несколькими предложениями выше при изменение Root Port с Gi0/0 на Gi1/0 на Switch2 был отправлен TCN. Если бы этого не произошло, то все MAC-адреса, изученные через порт Gi 0/0, оставались бы привязаны к Gi0/0. Например, MAC-адрес VPC5 и VPC7 несмотря на то, что STP завершит сходимость через 50 секунд, связь между VPC6 и VPC5, VPC7 не была бы восстановлена, так как все пакеты предназначенные VPC5, VPC7 отправлялись через Gi0/0. Надо было бы ждать не 50 секунд, а 300 секунд пока таблица MAC-адресов перестроится. При помощи TCN, время хранение изменилось с 300 секунд до 15 и пока интерфейс Gi1/0 на Switch3 проходил состояния Listening, а затем Learning и данные о MAC-адресах обновятся.

Также интересен вопрос, что произойдет, если мы заново включим интерфейс Gi0/1 на Switch1? При включение интерфейса Gi0/1, он, как и подобает, перейдет в состояние Listening и начнет рассылать BPDU. Как только Switch2 получит BPDU на порту Gi0/0, то сразу перевыберет свой Root Port, так как тут Cost будет наименьшем и начнет пересылать траффик через интерфейс Gi0/0, но нам необходимо подождать пока интерфейс Gi0/1 пройдет состояния Listening, Learning до Forwarding. И задержка будет уже не 50 секунд, а 30.

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

Источник

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. Сети для самых маленьких: Часть пятая. NAT и ACL
4. Сети для самых маленьких: Часть четвёртая. STP
3. Сети для самых маленьких: Часть третья. Статическая маршрутизация
2. Сети для самых маленьких. Часть вторая. Коммутация
1. Сети для самых маленьких. Часть первая. Подключение к оборудованию cisco
0. Сети для самых маленьких. Часть нулевая. Планирование

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

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

• проблему широковещательного шторма
• работу и настройку протокола STP и его модификаций (RSTP, MSTP, PVST, PVST+)
• технологию агрегации интерфейсов и перераспределения нагрузки между ними
• некоторые вопросы стабильности и безопасности
• как изменить схему существующей сети, чтобы всем было хорошо

Оборудование, работающее на втором уровне модели 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). BPDU бывают двух видов: конфигурационные (Configuration BPDU) и панические “ААА, топология поменялась!” TCN (Topology Change Notification BPDU). Первые регулярно рассылаются корневым свичом (и ретранслируются остальными) и используются для построения топологии, вторые, как понятно из названия, отсылаются в случае изменения топологии сети (проще говоря, подключенииотключении свича). Конфигурационные BPDU содержат несколько полей, остановимся на самых важных:

• идентификатор отправителя (Bridge ID)
• идентификатор корневого свича (Root Bridge ID)
• идентификатор порта, из которого отправлен данный пакет (Port ID)
• стоимость маршрута до корневого свича (Root Path Cost)

Что все это такое и зачем оно нужно, объясню чуть ниже. Так как устройства не знают и не хотят знать своих соседей, никаких отношений (смежности/соседства) они друг с другом не устанавливают. Они шлют 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” и происходит так:

1. Корневой свич посылает BPDU с полем Root Path Cost, равным нулю
2. Ближайший свич смотрит на скорость своего порта, куда BPDU пришел, и добавляет стоимость согласно таблице

   Скорость порта	Стоимость STP (802.1d)
   10 Mbps	100
   100 Mbps	19
   1 Gbps	4
   10 Gbps	2

3. Далее этот второй свич посылает этот BPDU нижестоящим коммутаторам, но уже с новым значением Root Path Cost, и далее по цепочке вниз

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

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

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

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

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

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

• блокировка (blocking): блокированный порт не шлет ничего. Это состояние предназначено, как говорилось выше, для предотвращения петель в сети. Блокированный порт, тем не менее, слушает BPDU (чтобы быть в курсе событий, это позволяет ему, когда надо, разблокироваться и начать работать)
• прослушивание (listening): порт слушает и начинает сам отправлять BPDU, кадры с данными не отправляет.
• обучение (learning): порт слушает и отправляет BPDU, а также вносит изменения в CAM- таблицу, но данные не перенаправляет.
• перенаправлениепересылка (forwarding): этот может все: и посылаетпринимает BPDU, и с данными оперирует, и участвует в поддержании таблицы mac-адресов. То есть это обычное состояние рабочего порта.
• отключен (disabled): состояние administratively down, отключен командой shutdown. Понятное дело, ничего делать не может вообще, пока вручную не включат.

Порядок перечисления состояний не случаен: при включении (а также при втыкании нового провода), все порты на устройстве с 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 для всех вланов. BPDU по транкам передаются нетегированными (в 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. PVST+ это протокол по умолчанию на коммутаторах 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 не нужно заново просчитывать топологию, он просто переключится на запасной, заранее просчитанный.

Ранее, для того, чтобы убедиться, что порт может участвовать в передаче данных, требовались таймеры, т.е. свич пассивно ждал в течение означенного времени, слушая BPDU. Ключевой фичей RSTP стало введение концепции типов портов, основанных на режиме работы линка- full duplex или half duplex (типы портов p2p или shared, соответственно), а также понятия пограничный порт (тип edge p2p), для конечных устройств. Пограничные порты назначаются, как и раньше, командой spanning-tree portfast, и с ними все понятно- при включении провода сразу переходим к forwarding-состоянию и работаем. Shared-порты работают по старой схеме с прохождением через состояния BLK — LIS — LRN — FWD. А вот на p2p-портах RSTP использует процесс предложения и соглашения (proposal and agreement). Не вдаваясь в подробности, его можно описать так: свич справедливо считает, что если линк работает в режиме полного дуплекса, и он не обозначен, как пограничный, значит, на нем только два устройства- он и другой свич. Вместо того, чтобы ждать входящих BPDU, он сам пытается связаться со свичом на том конце провода с помощью специальных proposal BPDU, в которых, конечно, есть информация о стоимости маршрута к корневому свичу. Второй свич сравнивает полученную информацию со своей текущей, и принимает решение, о чем извещает первый свич посредством agreement BPDU. Так как весь этот процесс теперь не привязан к таймерам, происходит он очень быстро- только подключили новый свич- и он практически сразу вписался в общую топологию и приступил к работе (можете сами оценить скорость переключения в сравнении с обычным STP на видео). В Cisco-мире RSTP называется PVRST (Per-Vlan Rapid Spanning Tree).

MSTP

Чуть выше, мы упоминали о PVST, в котором для каждого влана существует свой процесс STP. Вланы это довольно удобный инструмент для многих целей, и поэтому, их может быть достаточно много даже в некрупной организации. И в случае PVST, для каждого будет рассчитываться своя топология, тратиться процессорное время и память свичей. А нужно ли нам рассчитывать STP для всех 500 вланов, когда единственное место, где он нам нужен- это резервный линк между двумя свичами? Тут нас выручает MSTP. В нем каждый влан не обязан иметь собственный процесс STP, их можно объединять. Вот у нас есть, например, 500 вланов, и мы хотим балансировать нагрузку так, чтобы половина из них работала по одному линку (второй при этом блокируется и стоит в резерве), а вторая- по другому. Это можно сделать с помощью обычного 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-адреса получателей и отправителей и порты. Поэтому в случае возникновения вопроса: “Хей, а чего так плохо балансируется?” в первую очередь смотрите на алгоритм балансировки.

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

Port security

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

Для начала, следует упомянуть команду конфигурации интерфейса switchport port-security, включающую защиту на определенном порту свича. Затем, с помощью switchport port-security maximum 1 мы можем ограничить количество mac-адресов, связанных с данным портом (т.е., в нашем примере, на данном порту может работать только один mac-адрес). Теперь указываем, какой именно адрес разрешен: его можно задать вручную switchport port-security mac-address адрес, или использовать волшебную команду switchport port-security mac-address sticky, закрепляющую за портом тот адрес, который в данный момент работает на порту. Далее, задаем поведение в случае нарушения правила switchport port-security violation {shutdown | restrict | protect}: порт либо отключается, и потом его нужно поднимать вручную (shutdown), либо отбрасывает пакеты с незарегистрированного мака и пишет об этом в консоль (restrict), либо просто отбрасывает пакеты (protect).

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

DHCP Snooping

Другая возможная атака нацелена на DHCP сервер. Как мы знаем, DHCP обеспечивает клиентские устройства всей нужной информацией для работы в сети: ip-адресом, маской подсети, адресом шюза по умолчанию, DNS-сервера и прочим. Атакующий может поднять собственный DHCP, который в ответ на запрос клиентского устройства будет отдавать в качестве шлюза по умолчанию (а также, например, DNS-сервера) адрес подконтрольной атакующему машины. Соответственно, весь трафик, направленный за пределы подсети обманутыми устройствами, будет доступен для изучения атакующему — типичная man-in-the-middle атака. Либо такой вариант: подлый мошенник генерируют кучу DHCP-запросов с поддельными MAC-адресами и DHCP-сервер на каждый такой запрос выдаёт IP-адрес до тех пор, пока не истощится пул.

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

IP Source Guard

После включения DHCP Snooping’а, он начинает вести у себя базу соответствия MAC и IP-адресов устройств, которую обновляет и пополняет за счет прослушивания DHCP запросов и ответов. Эта база позволяет нам противостоять еще одному виду атак — подмене IP-адреса (IP Spoofing). При включенном IP Source Guard, каждый приходящий пакет может проверяться на:

• соответствие IP-адреса источника адресу, полученному из базы DHCP Snooping (иными словами, айпишник закрепляется за портом свича)
• соответствие MAC-адреса источника адресу, полученному из базы DHCP Snooping

Включается IP Source Guard командой ip verify source на нужном интерфейсе. В таком виде проверяется только привязка IP-адреса, чтобы добавить проверку MAC, используем ip verify source port-security. Само собой, для работы IP Source Guard требуется включенный DHCP snooping, а для контроля MAC-адресов должен быть включен port security.

Dynamic ARP Inspection

Как мы уже знаем, для того, чтобы узнать MAC-адрес устройства по его IP-адресу, используется проткол ARP: посылается широковещательный запрос вида “у кого ip-адрес 172.16.1.15, ответьте 172.16.1.1”, устройство с айпишником 172.16.1.15 отвечает. Подобная схема уязвима для атаки, называемой ARP-poisoning aka ARP-spoofing: вместо настоящего хоста с адресом 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.

Практика

Наверное, большинство ошибок в 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, где у нас, судя по схеме, петля.

msk-arbat-dsw1>en
msk-arbat-dsw1#show spanning-tree vlan 3

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

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

• собственно, порт
• его роль (Root- корневой порт, Desg- назначенный порт, Altn- дополнительный, Back- резервный)
• его статус (FWD- работает, BLK- заблокирован, LIS- прослушивание, LRN- обучение)
• стоимость маршрута до корневого свича
• Port ID в формате: приоритет порта.номер порта
• тип соединения

Итак, мы видим, что 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) вручную установить приоритет, заведомо меньший, чем текущий:

msk-arbat-dsw1>enable
msk-arbat-dsw1#configure terminal
msk-arbat-dsw1(config)#spanning-tree vlan 3 priority?
<0-61440> bridge priority in increments of 4096
msk-arbat-dsw1(config)#spanning-tree vlan 3 priority 4096

Теперь он стал корневым для влана 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

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

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

1. Лабораторная работа №1 «Развертывание коммутируемой сети с резервными каналами»

2. Лабораторная работа №2 «Настройка Rapid PVST+ PortFast и BPDU Guard»

3. Лабораторная работа №3 «Настройка протоколов HSRP и GLBP» 

4. Лабораторная работа №4 «Определение типовых ошибок конфигурации STP»

5. Лабораторная работа №5 «Настройка EtherChannel» 

5.1. Настройка EtherChannel_1 Скачать файл_1

6. Лабораторная работа №6 «Поиск и устранение неполадок в работе EtherChannel» Скачать файл

7. Лабораторная работа №7 «Агрегирование каналов. Настройка VRRP и EtherChannel»

8. Лабораторная работа №8 Настройка RIPv2 с VLSM и распространением маршрута по умолчанию

9. Лабораторная работа №9 «Настройка беспроводного маршрутизатора и клиента»

10. Лабораторная работа №10 «Настройка базового протокола OSPFv2 для одной области»

11. Лабораторная работа №11 «Настройка расширенных функций OSPFv2»

12. Лабораторная работа №12 «Поиск и устранение неполадок в работе усовершенствованного протокола OSPFv2 для одной области»

13. Лабораторная работа №13 «Базовая настройка протокола OSPFv3»

14. Лабораторная работа №14 «Поиск и устранение неполадок в работе основных протоколов OSPFv2 и OSPFv3 для одной области»

15. Лабораторная работа №15 «Настройка базового протокола OSPFv2 для множественного доступа»

16. Лабораторная работа №16 «Поиск и устранение неполадок в работе OSPFv2 и OSPFv3 для нескольких областей»

17. Лабораторная работа №17 «Базовая настройка протокола EIGRP с IPv4» Скачать файл

18. Лабораторная работа №18 «Базовая настройка протокола EIGRP с IPv6» Скачать файл

19. Лабораторная работа №19 «Ручная настройка суммарных маршрутов EIGRP для IPv4 и IPv6» Скачать файл

 20. Лабораторная работа №20 «Распространение маршрута по умолчанию в EIGRP для IPv4 и IPv6» Скачать файл

 21. Лабораторная работа №21 «Поиск и устранение неполадок базового EIGRP для IPv4 и IPv6»

 22. Лабораторная работа №22 «Настройка расширенных функций EIGRP для IPv4»

 23. Лабораторная работа № 23 «Поиск и устранение неполадок в работе расширенной версии EIGRP»

 24. Лабораторная работа №24 «Заключительный проект по EIGRP»

 25. Лабораторная работа №25 «Заключительный проект по OSPF»

 26. Лабораторная работа №26 «Поиск и устранение неполадок в работе последовательных интерфейсов» Скачать файл

 27. Лабораторная работа №27 «Настройка аутентификации протоколов PAP и CHAP» Скачать файл

 28. Лабораторная работа №28 «Отладка базового PPP с аутентификацией» Скачать файл

 29. Лабораторная работа №29 «Настройка подынтерфейсов «точка-точка» Frame Relay» Скачать файл

 30. Лабораторная работа №30 «Изучение принципа работы NAT» Скачать файл

30.1. Настройка статического NAT Скачать файл

30.2. Настройка динамического NAT Скачать файл

 31. Лабораторная работа №31 «Реализация статического и динамического NAT» Скачать файл

 31.1. Настройка преобразования адреса и номера порта (PAT)

 32. Лабораторная работа №32 «Отладка настроек NAT»

 32.1. Проверка и отладка настроек NAT Скачать файл

 33. Лабораторная работа №33 «Настройка маршрутизатора в качестве клиента PPPoE для подключения DSL»

 34.  Лабораторная работа №34 «Настройка сетей VPN» Скачать файл

 35. Лабораторная работа №35 «Настройка протокола GRE» Скачать файл_1 Скачать файл_2

 36. Лабораторная работа №36 «Настройка туннеля VPN GRE по схеме «точка-точка»» Скачать файл

 36.1. Настройка туннеля VPN GRE по схеме «точка-точка»

 37. Лабораторная работа №37 «Конфигурирование SYSLOG и NTP» Скачать файл

 37.1. Настройка протоколов Syslog и NTP

 38. Лабораторная работа №38 «Настройка SNMP»

 39. Лабораторная работа №39 «Сбор и анализ данных NetFlow»

40. Лабораторная работа №40 «Устранение проблем. Документирование сети» Скачать файл

41. Лабораторная работа №41 «Отладка корпоративных сетей 1-3»

41.1. Отладка корпоративных сетей 1 Скачать файл

41.2. Отладка корпоративных сетей 2 Скачать файл

41.3. Отладка корпоративных сетей 3 Скачать файл

42. Лабораторная работа №42 «Поиск и устранение неполадок. Использование документации для решения проблем» Скачать файл

Программы для лабораторных работ:

Скачать Cisco Packet Tracer

Скачать GNS3

Скачать образы для Cisco:

c2691

c3660

c3725

c3745

c7200

Скачать Wireshark

Команды CISCO

Введение в STP

Обзор STP:

Протокол Spanning Tree Protocol (STP) преобразует кольцевую сеть в сеть с ациклическим деревом, избегая распространения и бесконечной циркуляции пакетов в кольцевой сети.

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

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

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

Понятия, связанные с STP:

• Корневой мост

  Древовидная сетевая структура должна иметь корень дерева, поэтому STP / RSTP вводит понятие корневого моста (Root Bridge).

  Для сети STP / RSTP существует один и только один корневой мост, который является логическим центром всей сети, но не обязательно физическим центром. Однако корневой мост может измениться в соответствии с изменениями топологии сети.

• BID (идентификатор моста): идентификатор моста

  Стандарт IEEE 802.1d предусматривает, что BID состоит из 2-байтового приоритета моста (приоритет моста) и MAC-адреса моста, то есть BID (8 байтов) = приоритет моста (2 байта) + MAC-адрес моста (6 байтов). ,

  В сети STP в качестве корневого моста выбирается устройство с наименьшим идентификатором моста. На оборудовании Huawei приоритет моста поддерживает ручную настройку.

• PID (Port ID): ID порта

  PID состоит из двух частей: PID (16 бит) = приоритет порта (4 бита) + номер порта (12 бит).

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

• Стоимость пути (RPC)

  Стоимость пути — это эталонное значение, используемое протоколом STP / RSTP для выбора канала. Протокол STP / RSTP выбирает более «сильные» ссылки путем вычисления стоимости пути, блокирует избыточные ссылки и преобразует сеть в древовидную структуру без петель. Стоимость пути к портам корневого устройства равна 0.

  В сети STP / RSTP совокупная стоимость пути от порта к корневому мосту — это стоимость каждого порта на каждом мосту, который он проходит.

• PC（port cost）

  Расчет ПК должен производиться на основе пропускной способности порта.

Роль порта:

• Корневой порт (RP):

  То есть порт, ближайший к пути корневого моста. Корневой порт отвечает за пересылку данных в направлении корневого моста, а корневой порт также отвечает за получение пакетов BPDU от восходящих устройств и пересылку пользовательского трафика. Критерий выбора корневого порта основан на стоимости корневого пути. Среди всех портов с поддержкой STP на устройстве тот, у которого наименьшая стоимость корневого пути, является корневым портом. На устройстве, на котором работает протокол STP / RSTP, есть один и только один корневой порт, и на корневом мосте нет корневого порта.

• Назначенный порт (DR):

  Для коммутирующего устройства его назначенный порт — это порт, который пересылает пакеты BPDU нисходящему коммутационному устройству. Все порты корневого моста являются назначенными портами. Каждый сетевой сегмент кольцевой сети будет выбирать назначенный порт, а коммутационное устройство с назначенным портом в сетевом сегменте называется назначенным мостом сетевого сегмента.

• Альтернативный порт (AP):

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

Статус порта:

Три таймера:

Сообщение STP

Формат сообщения STP:

Рис.: Формат сообщения STP

Пояснения к полям сообщения:

Пример захвата пакета STP:

Рис.: Пример захвата пакета STP

Примечания к STP

Принцип STP:

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

Версия STP:

1. IEEE 802.1D STP
2. IEEE802.1W RSTP
3. IEEE802.1S (Huawei) MSTP

Процесс выборов STP:

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

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

   Примечание. У некорневого моста может быть только один корневой порт.

3. Для каждого канала необходимо выбрать назначенный порт. По умолчанию все порты корневого моста являются назначенными портами.

4. Другие порты, которые не являются ни корневым, ни назначенным портом, должны быть заблокированы и не могут пересылать кадры данных.

Выбор корневого моста:

1. При сравнении выборов BID, предпочтительно, чтобы BID был небольшим. BID состоит из приоритета + MAC-адреса.
2. Сначала сравните приоритеты, чем меньше приоритет, тем лучше.
3. Если приоритет одинаковый, сравните MAC-адреса. Чем меньше MAC-адрес, тем лучше.

Выборы по порту:

1. По сравнению с RID желательно небольшого размера.
2. Сравните стоимость корневого пути (RPC) с корневым мостом: чем меньше, тем лучше.
3. Сравните BID отправителя пакета BPDU, чем меньше, тем лучше.
4. Сравните PID отправителя пакета BPDU, чем меньше, тем лучше.
5. Сравните PID получателя пакетов BPDU, чем меньше, тем лучше.

Два типа пакетов BPDU:

• Настроить BPDU

  Содержит такие параметры, как идентификатор моста, стоимость пути и идентификатор порта.

• TCN BPDU

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

Ошибка STP:

• Сбой корневого моста

  Некорневой мост начнет переизбирать корневой мост после того, как BPDU устареет.

• Ошибка прямой ссылки

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

  Резервный порт вернется в состояние пересылки через 30 секунд.

• Отказ косвенной ссылки

  Для перехода непрямого канала в состояние пересылки требуется 50 секунд (MAX age + Forwarding delay * 2).

• Изменение топологии вызывает ошибку таблицы MAC-адресов

  По умолчанию время устаревания MAC-адреса составляет 300 с, в течение которого данные не могут быть отправлены.

STP используется для пакетов изменения топологии:

• Сообщение TCN BPDU: уведомление об изменении топологии.

• Пакеты TCN BPDU могут быть отправлены только некорневыми мостами и уведомлены корневому мосту.

• Сообщение TCA BPDU: используется для подтверждения полученного сообщения TCN PBDU.

• Сообщение TC BPDU: оно может быть инициировано только корневым мостом и отправлено непрерывно в течение 35 секунд (MAX age + Forwarding delay).

  После получения TC BPDU некорневой мост установит время устаревания MAC-адреса на 15 с, чтобы ускорить устаревание.

Изменения топологии STP:

1. Если на некорневом мосте происходит изменение топологии, на корневой мост отправляется пакет TCN BPDU, чтобы уведомить корневой мост об изменении топологии.
2. После того, как некорневой мост восходящей линии связи получит пакет TCN BPDU от назначенного порта, он ответит отправителю пакет BPDU конфигурации с установленным флагом TCA и продолжит отправку пакета TCN BPDU на корневой мост.
3. После получения пакета TCN BPDU корневой мост отвечает отправителю пакетом BPDU конфигурации с установленным флагом TCA и в то же время отправляет пакет BPDU конфигурации с установленным флагом TC на все назначенные порты. Пакет BPDU конфигурации с установленным TC будет отправляться непрерывно в течение 35 секунд, а его MAC-устаревание будет установлено на 15 секунд одновременно.
4. После получения пакета BPDU конфигурации, установленного TC, другие некорневые мосты устанавливают время устаревания своего MAC-адреса на 15 с, чтобы ускорить устаревание.

STP запускает условия изменения топологии:

1. Порт переходит из состояния пересылки в состояние отключения или блокировки.
2. Если некорневой мост получает пакеты TCN BPDU от назначенного порта, ему необходимо отправить пакеты TCN BPDU на корневой мост.
3. Порт переходит в состояние пересылки, а порт finger уже существует локально.

Командная строка конфигурации STP

stp mode { stp | rstp | mstp}
// Настраиваем режим работы коммутатора STP. По умолчанию коммутационное устройство работает в режиме MSTP, который совместим с режимами STP и RSTP.

stp root primary
// Настраиваем текущее устройство как устройство корневого моста. По умолчанию коммутационное устройство не действует как корневой мост какого-либо связующего дерева. После настройки значение BID приоритета устройства автоматически становится равным 0, и приоритет устройства нельзя изменить.

stp root secondary
// Настройте текущее коммутирующее устройство в качестве резервного корневого моста. По умолчанию коммутационное устройство не действует как резервный корневой мост для какого-либо связующего дерева. После настройки значение BID приоритета устройства составляет 4096, и приоритет устройства нельзя изменить.

stp priority 32768
// Настраиваем приоритет коммутирующего устройства в системе. По умолчанию значение приоритета коммутационного устройства составляет 32768. Во время настройки приоритет должен быть кратен 4096.

stp pathcost-standard { dot1d-1998 | dot1t | legacy }
// Настраиваем метод расчета стоимости пути к порту. По умолчанию метод расчета стоимости пути - стандартный метод IEEE 802.1t (dot1t).

 [Просмотр интерфейса] стандартная стоимость 100
// Устанавливаем значение стоимости пути для текущего порта.
// Диапазон значений параметра cost от 1 до 200000 при использовании метода расчета Huawei.
// Диапазон значений от 1 до 65535 при использовании стандартного метода IEEE 802.1d.
// Диапазон значений от 1 до 200000000 при использовании стандартного метода IEEE 802.1t.

 [Просмотр интерфейса] stp приоритет порта 128
// Настраиваем приоритет порта. По умолчанию значение приоритета порта коммутационного устройства составляет 128.

stp enable // Включаем функцию STP коммутирующего устройства. По умолчанию функция STP / RSTP устройства включена.

stp converge { fast | normal}
// Настраиваем режим конвергенции порта
// В соответствии с различными методами обработки записей ARP, методы сходимости STP / RSTP делятся на быстрые и обычные:
// быстро: таблица ARP напрямую удаляет записи, которые необходимо обновить.
// normal: элементы, которые необходимо быстро обновить в таблице ARP, возрастают.
// Коммутационное устройство устанавливает оставшееся время жизни этих записей в таблице ARP равным 0 и выполняет обработку устаревания этих записей. Если настроенное количество обнаружений устаревания ARP больше нуля, ARP выполнит обнаружение устаревания для этих записей.

// Рекомендуется выбрать метод нормальной сходимости. Если выбран быстрый режим, частое удаление записей ARP может привести к загрузке ЦП устройства до 100%, а таймауты обработки пакетов могут вызвать нестабильность сети.

stp bridge-diameter 5
// Настраиваем диаметр сети. По умолчанию диаметр сети равен 7.

stp timer-factor factor
// Настраиваем период ожидания для перезапуска вычисления связующего дерева без получения восходящих BPDU. По умолчанию период ожидания для перезапуска вычисления связующего дерева без получения восходящих BPDU в 9 раз превышает значение таймера Hello.

stp timer forward-delay 1500
// Настраиваем время задержки пересылки для устройства. По умолчанию время задержки пересылки устройства составляет 1500 сантисекунд (15 секунд).

stp timer hello 200
// Настраиваем время приветствия устройства. По умолчанию время приветствия устройства составляет 200 сантисекунд (2 секунды).

stp timer mac-age 2000
// Настраиваем максимальное время возраста устройства. По умолчанию максимальный возраст устройства составляет 2000 сантисекунд (20 секунд).

max bandwidth-affected-linknumber 8
// Настраиваем максимальное количество подключений, влияющих на пропускную способность. По умолчанию максимальное количество подключений, влияющих на пропускную способность агрегации каналов, равно 8.

reset stp error packet statistics 
// Очистить счетчик сообщений об ошибках протокола связующего дерева.

display stp toplogy-change
// Просмотр статистики, связанной с изменениями топологии STP / RSTP

Примеры конфигурации STP

Как показано на рисунке ниже, вам необходимо настроить SW1 как корневой мост, а SW2 как резервный корневой мост. При настройке STP в трехдневном коммутаторе определенный порт блокируется, чтобы предотвратить выход сети из цикла.

Рис.: Топология конфигурации STP

Файл конфигурации SW1:

[SW1]dis current-configuration 
#
sysname SW1
#
stp mode stp
stp instance 0 root primary
#

Файл конфигурации SW2:

[SW2]dis current-configuration 
#
sysname SW2
#
stp mode stp
stp instance 0 root secondary
#

Проверьте статус STP порта GI0 / 0/2 SW3:

Изображение: статус STP gi0 / 0/2 SW3

В том числе практических занятий и лабораторных работ

64

1

Развертывание коммутируемой сети с резервными каналами

2

2

Настройка Rapid PVST+, PortFast и BPDU Guard

2

3

Настройка протокола GLBP

2

4

Определение типовых ошибок конфигурации STP

2

5

Настройка EtherChannel

2

6

Поиск и устранение неполадок в работе EtherChannel

2

7

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

2

8

Настройка беспроводного маршрутизатора и клиента

2

9

Настройка базового протокола OSPFv2 для одной области

2

10

Настройка OSPFv2 в сети множественного доступа

2

11

Настройка расширенных функций OSPFv2

2

12

Поиск и устранение неполадок в работе основных протоколов OSPFv2 и OSPFv3 для одной области

2

13

Поиск и устранение неполадок в работе усовершенствованного протокола OSPFv2 для одной области

2

14

Владение навыками поиска и устранения неполадок в работе OSPF

2

15

Настройка OSPFv2 для нескольких областей

2

16

Настройка OSPFv3 для нескольких областей

2

17

Поиск и устранение неполадок в работе OSPFv2 и OSPFv3 для нескольких областей

Тема 2.2. Соединение сетей.

Содержание

144

1

Подключение к глобальной сети

Обзор технологий глобальной сети. Цель создания глобальных сетей. Принцип работы глобальной сети. Выбор технологии глобальной сети. Сервисы глобальной сети. Инфраструктуры частных глобальных сетей. Инфраструктура общедоступной глобальной сети. Выбор сервисов глобальной сети.

2

Соединение «точка-точка»

Обзор последовательного соединения «точка-точка». Связь по последовательному каналу. Инкапсуляция HDLC. Принцип работы протокола PPP. Преимущества протокола PPP. LCP и NCP. Сеансы PPP. Настройка протокола PPP. Настройка протокола PPP. Аутентификация PPP. Отладка соединений WAN. Отладка PPP.

3

Решения широкополосного доступа

Удалённая работа. Преимущества удалённой работы. Бизнес-требования для удалённых работников. Сравнение решений широкополосного доступа. Кабель. DSL. Беспроводные широкополосные сети. Выбор решений широкополосного доступа. Настройка подключений xDSL. Обзор PPPoE. Настройка PPPoE.

4

Защита межфилиальной связи

Сети VPN. Основы сетей VPN. Типы сетей VPN. Туннели GRE между объектами. Основы GRE. Настройка туннелей GRE. Общие сведения об IPsec. Защита протокола IP. Структура протокола IPsec. Удалённый доступ. Решения VPN для удалённого доступа. Сети VPN удалённого доступа с использованием IPsec.

5

Мониторинг Сети

Syslog. Принцип работы Syslog. Настройка Syslog. SNMP. Принцип работы SNMP. Настройка SNMP. NetFlow. Принцип работы NetFlow. Настройка NetFlow. Проверка моделей трафика.

6

Отладка сети

Поиск и устранение неполадок с использованием системного подхода. Документация по сети. Процедура поиска и устранения неполадок. Изоляция проблемы с помощью многоуровневых моделей. Отладка сети. Средства поиска и устранения неполадок. Симптомы и причины отладки сети. Поиск и устранение неполадок связи в сетях IP.

Основное правило — «Не делать предположение о том, что находится в рабочем состоянии, а что нет, предварительно этого не проверив». Т.е. нельзя предполагать, что порт коммутатора активен, и находится в рабочем состоянии, не проверив этого. Все остальное — по плану.

1. Диагностика физического уровня и порта коммутатора

·        Кабель: тип, категория, длинна

·        Состояние порта

·        Согласованность портов ( full-duplex / half-duplex )

·        Принадлежность порта корректному VTP VLAN

2. Диагностика и устранение неполадок VLAN и VTP-trunk-ов

·        Согласованность номера native VLAN на всех узлах VTP домена.

·        Согласованность режимов локального и удаленного VTP trunk-ов ( Dynamic Auto / Dynamic Desirable)

·        Принадлежность каждого VLAN уникальной IP сети

·        Параметры конфигурации для Inter-VLAN маршрутизации

3. Диагностика и устранение неполадок VTP

·        Наличие необходимых параметров конфигурации VLAN в running-config

·        Согласованность параметров VTP на всех коммутаторах

·        Появление проблем после добавления нового коммутатора

·        Отключение порта(ов) после включения питания коммутатора

4. Диагностика и устранение неполадок STP

·        Root-бридж по схеме сети

·        Петли коммутации

·        Лог изменения конфигурации STP

·        Процесс выбора root-бриджа

·        RSTP режим

1. Диагностика физического уровня и порта коммутатора

Первое что нужно сделать для выяснения возможных причин сбоев или полной неработоспособности сети — это проверить кабель. Не думаю, что в рамках экзаменационных вопросов встретится что-то кроме вопросов о правильности выбора типа используемого кабеля для различного оборудования. Речь идет о crossover ( перекрестный обжим ) straightthrough ( прямой обжим ) кабелях. Применения типа обжима в документации Cisco предлагается запомнить по простому принципу:

·       прямой ( straightthrough ) применяется для подключения оборудования разного типа;

·       перекрестный ( crossover ) — для подключения оборудования одного типа.

Разделить оборудование на типы можно по его положению относительно Ethernet сегмента — маршрутизаторы, клиентские станции и сервера являются конечными системами в сегменте сети Ethernet, в то время как повторители, хабы и свитчи являются основой его инфраструктуры. Из этого простого разделения и нужно исходить при выборе типа кабеля.

Далее необходимо проверить состояние портов на обеих сторонах неисправного соединения. Основная задач выяснить нет ли портов “disable” или “errDisable” ( в зависимости от причины вызвавшей отключение порта ).

Проверить состояние порта можно по выводу команды show для соответствующего интерфейса / порта

SwitchX# sh int fa0/2

FastEthernet0/2 is up, line protocol is up (connected)

  Hardware is Fast Ethernet, address is 0017.596d.2a02 (bia 0017.596d.2a02)

  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

          reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation ARPA, loopback not set

——————————-пропущено—————————————-

На следующем этапе необходимо проверить согласованность режимов портов. В документации Cisco рекомендуется отключать автоопределение портов, и устанавливать «вручную» необходимый режим. Такая практика позволяет избежать возможных ошибок автоматического определения режима работы порта коммутатора. В тоже время, она же может привести к ошибке конфигурирования. Выяснить согласованность режимов работы портов можно из вывода команды show interface для портов на обеих сторонах неработающего канала.

Switch#show interfaces f0/2

FastEthernet0/2 is up, line protocol is up (connected)

  Hardware is Lance, address is 000c.856c.0a01 (bia 000c.856c.0a01)

 BW 100000 Kbit, DLY 1000 usec,

          reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 100Mb/s

——————————-пропущено—————————————-

В случае, если порт находится в режиме access, и ему назначен номер несуществующего / или случайно удаленного VLAN, вывод команды show interface будет бесполезен для выяснения причины неработоспособности порта. В таком случае необходимую информацию может предоставить show interface interface switchport 

SwitchX# show interfaces fa0/2 switchport

Name: Fa0/2

Switchport: Enabled

Administrative Mode: static access

Operational Mode: static access

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: native

Negotiation of Trunking: Off

Access Mode VLAN: 5 (Inactive)

Trunking Native Mode VLAN: 1 (default)

Administrative Native VLAN tagging: enabled

Voice VLAN: None

——————————-пропущено—————————————-

На некоторых коммутаторах Cisco на таких портах индикатор светится немигающим оранжевым.

2. Диагностика и устранение неполадок VLAN и VTP-trunk-ов

Для нормального функционирования IEEE 802.1Q trunk-ов они должны быть сконфигурированы с одинаковым значением параметра native VLAN. Для того чтобы проверить это необходимо просмотреть вывод команды show interfaces interface switchport или show intrface trunk на коммутаторах, находящихся на обеих сторонах неработающего соединения.

SwitchX#show interface f0/1 switchport

Name: Fa0/1

Switchport: Enabled

Administrative Mode: trunk

Operational Mode: trunk

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: dot1q

Negotiation of Trunking: On

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 1 (default)

——————————-пропущено—————————————-

SwitchX#show interface trunk

Port        Mode         Encapsulation          Status        Native vlan

Fa0/1       on                  802.1q                trunking               1

——————————-пропущено—————————————-

Не знаю, какова вероятность именно такой неисправности в экзаменационной лабораторной работе или вопросе, так как при нормальных обстоятельствах коммутаторы должны “жаловаться” прямо в консоль о том, что значение native VLAN не согласовано.

Native VLAN mismatch discovered on FastEthernet0/1 (1), with Switch FastEthernet0/1 (99)

Для того чтобы установить одинаковое значение native VLAN на обоих коммутаторах, необходимо в режиме Interface Configuration Mode выполнить команду

SwitchX(config-if)#switchport trunk native vlan VLAN number

Кроме этого, к неисправности в работе trunk-ов может привести несогласованность параметра Administrative Mode. Это обусловлено тем, что в некоторых случаях возможен перевод порта в режим trunk автоматически, используя протокол DTP. Всю необходимую информацию можно узнать из вывода команды show interfaces interface switchport.

Различия между Dynamic Auto и Dynamic Desirable заключается в том, что в первом случае будет создано trunk — соединение в ответ на DTP – запрос, а во втором случае будет инициироваться попытка создания trunk – соединение и посылаться DTP – запрос. Если оба порта будут настроены Dynamic Auto, trunk — соединение не будет создано.

Чтобы установить желаемое значение параметра Administrative Mode, необходимо в режиме Interface Configuration Mode выполнить команду

SwitchX(config-if)#switchport mode MODE

Несмотря на то, что технологии, реализованные Cisco Systems, позволяют оборудованию в некоторых случаях производить автоконфигурирование, в официальной документации все параметры рекомендуется устанавливать самостоятельно. В данном случае, параметр Administrative Mode не является исключением, и ему должно быть присвоено значение trunk для портов, которые должны создавать trunk-соединение.

Для нормального взаимодействия между узлами в пределах одного VLAN необходимо чтобы эти узлы находились в одной IP-сети. И на оборот, если узлы разнесены в различные VLAN – в различных IP-сетях. В случае, если эти простые условия не будут соблюдены, бесполезно ожидать сетевого взаимодействия между этими двумя узлами. Для того, чтобы это проверить нет необходимости выполнения каких либо команд на коммутаторах, достаточно просто сопоставить значения VLAN и присвоенных узлам IP-адресов, полученных из вывода команды ipconfig.

В случае возникновения неисправностей interVLAN взаимодействия, возможной причиной может быть неправильная конфигурация оборудования, вовлеченного в него. Это в первую очередь касается конечных узлов, на которых может быть неправильно сконфигурирован шлюз по умолчанию. Проверить правильность настроек интерфейса на конечно станции можно командой ipconfig

Следующей причиной подобных проблем может являться неправильная конфигурация роутера, обеспечивающего interVLAN – маршрутизацию. Для выяснения возможных неисправностей необходимо четко представлять нормальных алгоритм работы InterVLAN — маршрутизации. Основной причиной возникновения неисправностей interVLAN взаимодействия может являть неправильная конфигурация одного или нескольких дополнительных интерфейсов на маршрутиазторе. Это может быть, как неправильно настроенные параметры инкапсуляции IEEE 802.1Q, так и неправильное присвоение адреса. Для того, чтобы получить необходимую информацию можно просмотреть текущую конфигурацию маршрутизатора командой

show running-config

——————————-пропущено—————————————-
!
interface FastEthernet0/0.20
encapsulation dot1Q 20
 ip address 192.168.20.1 255.255.255.0
!
interface FastEthernet0/0.30
 encapsulation dot1Q 30
 ip address 192.168.30.1 255.255.255.0
!
interface FastEthernet0/0.40
 encapsulation dot1Q 40
 ip address 192.168.40.1 255.255.255.0
!
——————————-пропущено—————————————-

или просмотрев вывод команды

show interface sub-if name

Номер дополнительного интерфейса не обязательно должен соответствовать номеру VLAN ( такое соответствие упрощает понимание конфигурации и дальнейшее администрирование ), в то время как параметр Vlan ID – обязательно должен соответствовать номеру VLAN. Кроме того, адрес, присвоенный дополнительному интерфейсу, должен быть согласован с планом адресации в пределах обслуживаемого VLAN, а также быть эквивалентным адресу основного шлюза для этого VLAN.     

3. Диагностика и устранение неполадок VTP

Интересным явлением, с точки зрения возможности появления  в экзаменационном вопросе со статусом неисправности, является различие в способе сохранения информации протокола VTP и базы данных VLAN на коммутаторах с различными режимами протокола VTP. Такая нелогичность не может быть пропущена авторами экзамена.

Коммутаторы в VTP — режиме  Server и Client хранят всю информацию протокола VTP ( включая базу VLAN ) в файле vlan.dat. В то время, как коммутаторы в режиме Transparent — в файле конфигурации. Это различие может быть причиной неожиданных последствий выполнения команд

write erase

delete flash:vlan.dat

Более комплексной проблемой является отсутствие обмена данными между коммутаторами в пределах одного VTP домена. Для этого существует достаточно большое количество объективных причин..

Так как информация распространяется только через trunk-и, необходимо проверить являются ли порты, соединяющие коммутаторы, trunk-ами. Сделать это можно командой show interface trunk

SwitchX#show interface trunk

Port        Mode         Encapsulation          Status        Native vlan

Fa0/1       on                  802.1q                trunking               1

Fa0/2       on                  802.1q                trunking               1

Fa0/3       on                  802.1q                trunking               1

——————————-пропущено—————————————-

 Далее необходимо проверить параметры VTP домена domain и password. Оба параметра являются чувствительными к регистру. Если допустить ошибку в имени VTP домена или пароле, то обмен информацией не будет происходить.  Получить информацию о имени домена можно при помощи команды show vtp status

SwitchX#show vtp status
VTP Version : 2
Configuration Revision : 0
Maximum VLANs supported locally : 255
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name : Cisco
——————————-пропущено—————————————-

Для того, чтобы исключить возможное различие между настройками пароля на коммутаторах, вовлеченных в проблему, необходимо временно сбросить VTP пароль. Для этого необходимо в Global Configuration Mode выполнить команду no vtp password.

Версии протокола VTP не являются совместимыми. Если в VTP – домене есть коммутаторы, не поддерживающие VTP V2,  то его (VTP V2) нельзя использовать. В случае если все коммутаторы поддерживают VTP V2,  достаточно активировать эту версию протокола на коммутаторе, который является сервером для данного VTP домена, и все остальные коммутаторы автоматически перейдут на эту версию. По умолчанию используется  VTP V1.

Коммутаторы, использующие версию протокола VTP V1 и находящиеся в режиме Transparent, распространяют информацию только по VTP домену, к которому они принадлежат. Обновления, имеющие отношение к другим VTP доменам уничтожаются. В случае, если подобный коммутатор использует версию протокола VTP V2, то обновления имеющие отношение к другим VTP доменам передаются.  Посмотреть какая версия протокола VTP используется можно при помощи команды show vtp status.

SwitchX#show vtp status
VTP Version :2
Configuration Revision : 0
Maximum VLANs supported locally : 255
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name : Cisco
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
——————————-пропущено—————————————-

Параметр VTP Version  указывает на возможность использования VTP V2.  Значение Disabled  для параметра VTP V2 Mode указывает на то, что коммутатор использует VTP V1

Номера VLAN из дополнительного диапазона (от 1025 до 4094 ) не распространяются автоматически. VLAN-ы с номерами из этого диапазона, должны настраиваться на каждом коммутаторе отдельно.

Обновления не вносят изменения в конфигурацию клиент в том случае, если Configuration Revision у клиента выше, чем в пришедшем от сервера обновлении. Посмотреть значение Configuration Revision   можно в выводе команды show vtp status.

Так как на коммутаторах Cisco по умолчанию значение VTP Operating Mode установлено Server,  и при некоторых обстоятельствах  Configuration Revision может быть выше чем у коммутатора используемого в качестве сервера для VTP домена, то в такой ситуации вновь добавленный коммутатор может изменить существующую базу VLAN. В случае, если его база VLAN будет пустой, то все VLAN будут удалены. Следствием этого может быть ситуация, когда абсолютно все порты  на коммутаторах, после включения питания, не активны (  как было описано в п. 1 ), так как принадлежат не существующим VLAN. Для того, чтобы избежать подобной ситуации необходимо на вновь добавляемом коммутаторе обнулить значение  Configuration Revision переведя его сначала в режим Transparent, а потом в режим Server. Или сначала изменив значение  VTP Domain Name на любое другой, а потом вернув нужное значение. В обоих случаях  значение параметра Configuration Revision обнулится.

4. Диагностика и устранение неполадок STP

Диагностика и устранение неполадок протокола STP возможна только в случае  нормального документирования топологии сети. Это подразумевает наличие информации о том, какой коммутатор является Root, какие каналы являются резервными и какие порты находятся в заблокированном состоянии.   Только в этом случае возможна дальнейшая диагностика.  Это необходимо для того, чтобы прежде чем  искать что починить, иметь представление о том, как это все работало до того

Чтобы выявить несоответствия реального положения дел в сети и документации, достаточно использовать команду show spanning-tree. Из вывода данной команды можно определить какой коммутатор является в данный момент Root, в также текущее состояние портов относительно STP топологии.

Для быстрого восстановления работоспособности сети, разъединить петли коммутации. Для этого нужно отключить те порты коммутаторов, которые их образуют. И в этом случае документация STP топологии будет незаменима. Так основанием для принятия решения какие порты блокировать будет информация о том, какие порты были заблокированы.

SwitchX (config)#spanning-tree vlan VLAN ID root primary.

Время конвергенции ( схождения ) сети при использовании 802.1d и PVST+ составляет 30 -50 секунд. В случае использования RSTP и PVRST+ — не более 2-х секунд. При таком соотношении, использование режима pvst неприемлемо. В случае если схождение сети происходит медленней, чем ожидается, возможно, не все коммутаторы настроены на использование PVRST+. Какой режим используется в данный момент можно выяснить из первой строки вывода команды  show spanning-tree summary.