Усиление функции защиты Portfast BPDU для протокола STP
Параметры загрузки
Об этом переводе
Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.
Содержание
Общие сведения
Предварительные условия
Требования
Для данного документа специфических требований нет.
Используемые компоненты
Следующие версии ПО включили в себя защиту STP PortFast BPDU:
OС Catalyst (CatOS) версии 5.4.1 для платформ Catalyst 4500/4000 (Supervisor Engine II), 5500/5000, 6500/6000, 2926, 2926G, 2948G и 2980G;
Программное обеспечение Cisco IOS® выпуска 12.0(7)XE для платформ Catalyst 6500/6000;
Программное обеспечение Cisco IOS выпуска 12.1(8a)EW для Catalyst 4500/4000 Supervisor Engine III;
Программное обеспечение Cisco IOS выпуска 12.1(12c)EW для Catalyst 4500/4000 Supervisor Engine IV;
Программное обеспечение Cisco IOS выпуска 12.0(5)WC5 для серии Catalyst 2900XL и 3500XL;
Программное обеспечение Cisco IOS выпуска 12.1(11)AX для коммутаторов серии Catalyst 3750;
Программное обеспечение Cisco IOS выпуска 12.1(14)AX для коммутаторов Catalyst 3750 Metro;
Программное обеспечение Cisco IOS выпуска 12.1(19)EA1 для коммутаторов серии Catalyst 3560;
Программное обеспечение Cisco IOS выпуска 12.1(4)EA1 для коммутаторов серии Catalyst 3550;
Программное обеспечение Cisco IOS выпуска 12.1(11)AX для коммутаторов серии Catalyst 2970;
Программное обеспечение Cisco IOS выпуска 12.1(12c)EA1 для коммутаторов серии 2955;
Программное обеспечение Cisco IOS выпуска 12.1(6)EA2 для коммутаторов серии Catalyst 2950;
Программное обеспечение Cisco IOS выпуска 12.1(11)EA1 для коммутаторов Long-Reach Ethernet (LRE) Catalyst 2950;
Программное обеспечение Cisco IOS выпуска 12.1(13)AY для коммутаторов серии Catalyst 2940.
Примечание. Функция STP PortFast защиты BPDU не является доступной для коммутаторов серии Catalyst 8500, 2948G-L3 или 4908G-L3.
Информация, содержащаяся в данном документе, была получена в специально созданных лабораторных условиях. Все устройства, описанные в данном документе, начинали работу с очищенной (стандартной) конфигурацией. При работе с реально функционирующей сетью необходимо полностью осознавать возможные результаты использования всех команд.
Условные обозначения
См. «Технические рекомендации Cisco. Условные обозначения» для получения дополнительной информации об условных обозначениях, встречающихся в данном документе.
Описание функции
STP перенастраивает ячеистую топологию в свободную от петель древоподобную структуру. При включении канала в порту моста, в данном порту осуществляется вычисление STP. Результатом вычисления станет переход порта в состояние пересылки или блокировки. Этот результат зависит от положения порта в сети и параметров STP. Вычисление и переходный период занимают, как правило, от 30 до 50 секунд. В течение этого времени данные пользователя через порт не проходят. За этот период время ожидания некоторых пользовательских приложений может истечь.
Для немедленного перехода порта в состояние пересылки активизируйте функцию STP PortFast. Portfast переводит порт в режим пересылки STP сразу после включения канала. При этом порт все еще участвует в STP. Таким образом, если порт должен являться частью цикла, он в конечном итоге переходит в режим блокировки STP.
Так как данный порт участвует в STP, какое-то устройство может взять на себя функцию корневого моста и повлиять на активную STP топологию. Для осуществления функции корневого моста, данное устройство должно подключиться к порту и запустить STP с приоритетом моста более низким, чем у текущего корневого моста. Если другое устройство таким образом берет на себя функцию корневого моста, оно приводит сеть в условно оптимальное состояние. Это представляет собой простую форму атаки на сеть типа «отказ в обслуживании» (DoS). Временное введение и последующее удаление STP устройств с низким (0) приоритетом моста приводит к постоянному пересчету STP.
Новая функция STP PortFast защиты BPDU позволяет разработчикам сетей устанавливать границы домена STP и сохранять предсказуемость активной топологии. Устройства, находящиеся в сети после портов с включенной функцией STP PortFast, не могут повлиять на топологию STP. При приеме BPDU операция защиты BPDU отключает порт, работающий в режиме PortFast. Защита BPDU переводит порт в состояние отключения в результате ошибки и выводит на консоль сообщение. Например, сообщение может быть следующим:
Рассмотрим следующий пример:
Рисунок 1
Мост А имеет приоритет 8192 и является корневым для VLAN. Мост B имеет приоритет 16384 и является резервным корневым мостом для той же сети VLAN. Мосты А и В, соединенные каналом Gigabit Ethernet, образуют ядро сети. Мост С является коммутатором доступа и имеет работающий в режиме PortFast порт, подключающий его к устройству D. Если стандартными являются другие параметры STP, то порт моста С, соединяющий его с мостом В, находится в состоянии блокировки STP. Устройство D (ПК) не является частью STP. Пунктирные стрелки обозначают направление потока STP BPDU.
Рисунок 2
На рисунке 2 устройство D становится частью STP. Например, на ПК запущено приложение, работающее на базе Linux. Если приоритет программного моста равен 0 или его приоритет ниже приоритета корневого моста, программный мост берет на себя функцию корневого. Канал Gigabit Ethernet, соединяющий два основных коммутатора, переходит в режим блокировки. Такой переход вызывает поток всех данных в этой VLAN через канал с пропускной способностью 100 Mбит/с. Если через ядро этой VLAN проходит больше данных, чем канал может вместить, некоторые кадры будут сброшены. Сброс кадров приводит к потере соединения.
Функция STP PortFast защиты BPDU предотвращает возникновение подобной ситуации. Эта функция отключает порт в тот самый момент, когда мост С получает STP BPDU от устройства D.
Настройка
Вы можете подключить или отключить функцию STP PortFast глобальной защиты BPDU, которая затронет все порты, имеющие функцию PortFast. По умолчанию защита BPDU STP отключена. Введите следующую команду для того, чтобы включить функцию STP PortFast защиты BPDU для коммутатора:
Команда CatOS
Команда ПО Cisco IOS
Когда защита BPDU STP отключает порт, порт остается выключенным до тех пор, пока его не включат вручную. Вы можете настроить порт таким образом, чтобы после перехода в состояние отключения в результате ошибки он включался автоматически. Введите следующие команды, устанавливающие интервал времени ожидания при отключении в результате ошибки и включающие функцию времени ожидания:
Команды CatOS
Команды ПО Cisco IOS
Примечание: По умолчанию время ожидания составляет 300 секунд, а функция отключения по таймауту ожидания отключена.
Мониторинг
Для того, чтобы проверить, включена ли эта функция, введите следующую команду:
STP в Cisco
Материал из Xgu.ru
 |
| Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной. |
Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.
На этой странице описывается процедура настройки различных версий протокола Spanning Tree на коммутаторах Cisco.
Содержание
[править] Петли в сети
Петли в коммутируемой сети могут возникнуть по нескольким причинам:
[править] Настройки по умолчанию
Настройки STP по умолчанию (для коммутатора 3550):
| Настройка | Значение по умолчанию | |||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Состояние | Включен в VLAN 1 | |||||||||||||||||||||||||||||||||||||||
| Режим spanning-tree | PVST+ (Rapid PVST+ и MSTP выключены) | |||||||||||||||||||||||||||||||||||||||
| Приоритет коммутатора | 32768 | |||||||||||||||||||||||||||||||||||||||
| Приоритет портов (настраивается для каждого порта отдельно) | 128 | |||||||||||||||||||||||||||||||||||||||
| Стоимость порта (настраивается для каждого порта отдельно) | ||||||||||||||||||||||||||||||||||||||||
| Приоритет порта в VLAN (настраивается для каждого VLAN отдельно) | 128 | |||||||||||||||||||||||||||||||||||||||
| Стоимость порта в VLAN (настраивается для каждого VLAN отдельно) |
| Функция | Значение по умолчанию |
|---|---|
| Port Fast, BPDU filtering, BPDU guard | Глобально выключены |
| UplinkFast | Глобально выключена |
| Cross-Stack UplinkFast (CSUF) | Выключена на всех интерфейсах |
| BackboneFast | Глобально выключена |
| EtherChannel guard | Глобально включена |
| Root guard | Выключена на всех интерфейсах |
| Loop guard | Выключена на всех интерфейсах |
[править] Port Fast
Portfast — функция, которая позволяет порту пропустить состояния listening и learning и сразу же перейти в состояние forwarding. Настраивается на портах уровня доступа, к которым подключены пользователи или сервера.
Фактически, PortFast меняет две вещи в стандартной работе STP:
Когда на интерфейсе включен PortFast, он все равно отправляет BPDU.
Но, если включить PortFast на портах, которые соединены с другими коммутаторами, то есть риск создания петли. Так как, после получения BPDU порт остается в состоянии Forwarding. За это время, уже может образоваться петля.
Поэтому, в связке с PortFast, как правило, используется BPDUGuard (хотя и это, конечно же, не даст 100% гарантии, что не будет петли).
[править] Настройка Port Fast
Синтаксис команды для настройки Port Fast на интерфейсе:
Настройка Port Fast на access-интерфейсе:
Настройка Port Fast на интерфейсе, который работает в режиме trunk (тегированый порт):
Если на интерфейсе, который работает в режиме транка выполнить команду без параметра trunk, то функция Port Fast не будет применена.
Функцию Port Fast можно настроить глобально на всех интерфейсах в режиме access:
Отключить Port Fast на интерфейсе:
[править] Просмотр информации о настройках Port Fast
Просмотр информации о статусе функции Port Fast на интерфейсе:
Просмотр информации о настройках spanning-tree на интерфейсе:
Если Port Fast была включена глобально на всех access-портах, то это можно посмотреть в суммарной информации о настройках STP на коммутаторе:
[править] UplinkFast
Проприетарное усовершенствование протокола 802.1D сделанное Cisco. В RSTP эта функция не используются, так как улучшения уже встроены в протокол.
После включения UplinkFast на коммутаторе:
Если основной RP выходит из строя, то коммутатор сразу переключается на запасной и переводит его в состояние forward.
Кроме того, UplinkFast позволяет коммутаторам обновить записи в таблицах коммутации, без использования TCN. Вместо TCN коммутатор находит MAC-адреса всех локальных устройств и отправляет один multicast фрейм с каждым MAC-адресом в поле отправитель. Удаляются также остальные записи в таблицы коммутации самого коммутатора.
[править] BackboneFast
Проприетарное усовершенствование протокола 802.1D сделанное Cisco. В RSTP эта функция не используются, так как улучшения уже встроены в протокол.
Позволяет быстрее найти альтернативный путь, после изменения топологии. Для того чтобы функция работала, необходимо включить её на всех коммутаторах в сети.
[править] Безопасность STP
[править] BPDU Guard
BPDU Guard — функция, которая позволяет выключать порт при получении BPDU.
Может быть включена глобально на коммутаторе или на интерфейсе, у этих режимов есть некоторые отличия:
[править] Настройка BPDU Guard
Включение BPDU Guard глобально на коммутаторе, на портах с включенной функцией Port Fast:
Хотя в команде, которая включает BPDU Guard глобально на коммутаторе, есть параметр portfast, применение этой команды не включает функцию Port Fast. Она должна быть настроена отдельно.
Настройка BPDU Guard на интерфейсе:
[править] Просмотр информации о настройках BPDU Guard
Просмотр информации о настройках spanning-tree на интерфейсе:
Если функция BPDU Guard была включена глобально на коммутаторе, то это можно посмотреть в суммарной информации о настройках STP на коммутаторе:
[править] BPDU Filtering
BPDU Filtering — после включения функции, порт не принимает и не отправляет BPDU.
Может быть включена глобально на коммутаторе или на интерфейсе, у этих режимов есть некоторые отличия:
Возможные комбинации при включении BPDU Filtering глобально или на интерфейсе:
| Настройка на интерфейсе | Глобальная настройка | Состояние PortFast | Состояние PortFast BPDU Filtering |
|---|---|---|---|
| По умолчанию | Включена | Включена | Включена |
| По умолчанию | Включена | Отключена | Отключена |
| По умолчанию | Отключена | Не применимо | Отключена |
| Отключена | Не применимо | Не применимо | Отключена |
| Включена | Не применимо | Не применимо | Включена |
[править] Настройка BPDU Filtering
Включение BPDU Filtering глобально на коммутаторе, на портах с включенной функцией Port Fast:
Хотя в команде, которая включает BPDU Filtering глобально на коммутаторе, есть параметр portfast, применение этой команды не включает функцию Port Fast. Она должна быть настроена отдельно.
Настройка BPDU Filtering на интерфейсе:
[править] Просмотр информации о настройках BPDU Filtering
Просмотр информации о настройках spanning-tree на интерфейсе:
Если функция BPDU Filtering была включена глобально на коммутаторе, то это можно посмотреть в суммарной информации о настройках STP на коммутаторе:
[править] Root Guard
Включение Root Guard на интерфейсе (переводит порт в роль designated):
Посмотреть какие порты в состоянии inconsistent:
[править] Loop Guard
Одна из проблем с STP в том, что само оборудование, которое его использует, может быть причиной сбоя и создания петли. Для предотвращения подобных сбоев и была создана функция Loop Guard.
Описание Loop Guard
Как только на порт снова начинают поступать BPDU порт переводится в состояние согласно содержанию пакетов BPDU, а в логах появится следующее сообщение:
На каких портах следует включать Loop Guard? Наиболее очевидный ответ blocking. Однако это не всегда правильно. Loop guard должен быть включен на non-designated портах (более точно root и alternate портах).
По умолчанию Loop guard выключен. Для того что бы его включить используйте следующие команды:
Что бы включить Loop guard глобально:
Команда для проверки статуса Loop Guard:
[править] UDLD
[править] Совместимость и отличия функций
[править] Loop Guard в сравнении с UDLD
Функции Loop Guard и UDLD (Unidirectional Link Detection) частично совпадают друг с другом. Обе эти функции предназначены для борьбы с последствиями сбоев в функциональности STP. Однако есть небольшие отличия в функциональности.
Настройка оборудования Cisco. Протокол STP.
Кратко обсудим оборудование второго уровня модели OSI. Какие функции оно должно выполнять?
> Запоминание адресов (MAC-таблица);
> Перенаправление (коммутация) пакетов, читай, фреймов;
> Защита от петель (loop) в сети.
Про первое понятно, ведь у каждого коммутатора имеется таблица сопоставления MAC-адресов и портов (т.н. CAM-table — Content Addressable Memory Table), об этом мы уже говорили и повторяли не раз. Коммутатор запоминает MAC-адрес отправителя и порт, с которого пришел фрейм. Теперь коммутатор должен передать фрейм на порт, где находится MAC, указанный в качестве адреса назначения. Но если коммутатор только включили и таблица попросту пуста? Тогда коммутатор отправляет фрейм на все порты кроме порта-источника. Конечные хосты проверяют параметр destination address и если он не совпадает с их, то дропают фрейм. А вот устройство-получатель в ответном кадре указывает свой MAC, и вот уже CAM-таблица пополнилась информацией, теперь коммутатор знает на какой порт слать фреймы с искомым адресом. В следующий раз коммутатор не будет делать широковещательную рассылку, а отправит данные на нужный порт. Содержимое CAM-таблицы можно посмотреть командой show mac address-table, а на коммутаторах фирмы Dlink, например, это делается командой show fdb. Содержимое таблицы не хранится вечно, по-умолчанию у цисок MAC адрес удаляется из таблицы, если к нему не обращались более 300 секунд.
Всё, мы теперь познали дзэн коммутации. А теперь что такое петли?
3. BPDU второго свича будет, которые он разошлет нижестоящим коммутаторам, уже с новым значением Root Path Cost. И далее по цепочке.
В случае одинаковой стоимости конечного пути выбор упадет на меньший порт, и он станет корневым.
Мы тут обмолвились о состоянии блокировки порта, но помимо этого порт может находиться и в других агрегатных состояниях.
В обычном 802.1D STP существует пять состояний:
1. Блокировка (blocking): блокированный порт не шлет ничего. Это состояние предназначено, как говорилось выше, для предотвращения петель в сети. Блокированный порт, тем не менее, слушает BPDU (чтобы быть в курсе событий, это позволяет ему, когда надо, разблокироваться и начать работать);
2. Прослушивание (listening): порт слушает и начинает сам отправлять BPDU, кадры с данными не отправляет;
3. Обучение (learning): порт слушает и отправляет BPDU, а также вносит изменения в CAM-таблицу, но данные не перенаправляет;
4. Перенаправление\пересылка (forwarding): этот может все: и посылает\принимает BPDU, и с данными оперирует, и участвует в поддержании таблицы mac-адресов. То есть это обычное состояние рабочего порта;
5. Отключен (disabled): состояние administratively down, отключен командой shutdown. Понятное дело, ничего делать не может вообще, пока вручную не включат.
Порядок перечисления состояний не случаен, при включении коммутатора (также при поднятии нового линка) порты проходят все эти состояния за исключением, понятное дело, пятого. Зачем же такие сложности? STP очень осторожен, ведь на другом конце кабеля может быть свич, а это потенциальная петля. Поэтому сначала порт в течение 15 секунд (по-умолчанию) слушает приходящие на него BPDUшки, осознавая свое положение в сети. Еще 15 секунд порт лёрнит MAC-адреса в свою CAM-таблицу, и только полностью убедившись, что ничего не поломает, начинает нормальную работу. В итоге имеем аж 30 секунд простоя, что вообще говоря крайне нежелательно, даже компьютеры и те быстрее грузятся. Что делать?
Но какой бы вариант 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-адреса получателей и отправителей и порты. Поэтому в случае возникновения вопроса: “Хей, а чего так плохо балансируется?” в первую очередь смотрите на алгоритм балансировки.
2. Теперь запустим протокол в нужном VLAN:
3. Указываем доверенные порты, делается это в режиме конфигурирования уже конкретного интерфейса.
Примечание. В случае, если аплинком у вас выступает агрегированный интерфейс EtherChannel, то доверенным нужно сделать не только логический интерфейс Port-channel (Po), но и входящие в него физические.
Отлично, мы включили DHCP Snooping и он сейчас работает в 100 VLAN, а трастовым портом у него является Gi1/0/1. В общих случая дальнейшая настройка не требуется.
Дальше уже тонкая настройка. Что бы нам сделать. Давайте отрубим опцию 82 (Option 82):
Или, к примеру, порезать количество DHCP-реквестов:
Также давайте еще раз пройдемся по командам просмотра.
Так мы сможем посмотреть состояние DHPC Snooping:
А так посмотрим на таблицу соответствия мака, порта, айпи и влана:
Сразу внесем соответствующие изменения в документацию.
Теперь посмотрим, как в данный момент у нас самонастроился STP. Нас интересует только VLAN0003, где у нас, судя по схеме, петля.
Видим мы следующее:
Теперь для VLAN 3 наш msk-arbat-dsw1 стал корневым, т.к. теперь имеет меньший Bridge ID:
2. Также можно дать железке самой всё решить:
Теперь полюбуемся, как работает STP: заходим в командную строку на ноутбуке PTO1 и начинаем бесконечно пинговать наш почтовый сервер (172.16.0.4). Пинг сейчас идет по маршруту ноутбук-asw3-dsw1-gw1-dsw1(ну тут понятно, зачем он крюк делает — они из разных вланов)-asw2-сервер. А теперь поработаем Годзиллой из SimСity: нарушим связь между dsw1 и asw2, вырвав провод из порта (замечаем время, нужное для пересчета дерева).
Пинги пропадают, STP берется за дело, и за каких-то 30 секунд коннект восстанавливается. Годзиллу прогнали, пожары потушили, связь починили, втыкаем провод обратно. Пинги опять пропадают на 30 секунд! Мда-а-а, как-то не очень быстро, особенно если представить, что это происходит, например, в процессинговом центре какого-нибудь банка.
Но у нас есть ответ медленному PVST+! И ответ этот — Быстрый PVST+ (так и называется, это не шутка: Rapid-PVST). Посмотрим, что он нам дает. Меняем тип STP на всех свичах в Москве командой конфигурационного режима: spanning-tree mode rapid-pvst
Снова запускаем пинг, вызываем Годзиллу… Эй, где пропавшие пинги? Их нет, это же Rapid-PVST. Как вы, наверное, помните из теоретической части, эта реализация STP, так сказать, “подстилает соломку” на случай падения основного линка, и переключается на дополнительный (alternate) порт очень быстро, что мы и наблюдали. Ладно, втыкаем провод обратно. Один потерянный пинг. Неплохо по сравнению с 6-8, да?
Попробуем расширить канал, и на помощь призовем EtherChannel. В данный момент у нас соединение идет от fa0/2 dsw1 на Gi1/1 asw3, отключаем провод. Смотрим, какие порты можем использовать на asw3: ага, fa0/20-24 свободны, кажется. Вот их и возьмем. Со стороны dsw1 пусть будут fa0/19-23. Соединяем порты для EtherChannel между собой. На asw3 у нас на интерфейсах что-то настроено, обычно в таких случаях используется команда конфигурационного режима default interface range fa0/20-24, сбрасывающая настройки порта (или портов, как в нашем случае) в дефолтные.
Можно поотрубать настройки вручную и вообще погасить порты, как говорится, во избежание:
Делаем тоже самое на dsw1:
Теперь поднимаем интерфейсы на asw3, наш EtherChannel готов и занимает теперь аж пять физических линков. В конфиге мы увидим его под названием interface Port-channel 1.
Настраиваем транк (повторить также для dsw1):