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. Однако есть небольшие отличия в функциональности.
Spanning Tree Protocol Root Guard Enhancement
Available Languages
Download Options
Contents
Introduction
This document explains the Spanning Tree Protocol (STP) root guard feature. This feature is one of the STP enhancements that Cisco created. This feature enhances switched network reliability, manageability, and security.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
This document is not restricted to specific software and hardware versions.
Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Feature Description
The standard STP does not provide any means for the network administrator to securely enforce the topology of the switched Layer 2 (L2) network. A means to enforce topology can be especially important in networks with shared administrative control, where different administrative entities or companies control one switched network.
The forwarding topology of the switched network is calculated. The calculation is based on the root bridge position, among other parameters. Any switch can be the root bridge in a network. But a more optimal forwarding topology places the root bridge at a specific predetermined location. With the standard STP, any bridge in the network with a lower bridge ID takes the role of the root bridge. The administrator cannot enforce the position of the root bridge.
Note: The administrator can set the root bridge priority to 0 in an effort to secure the root bridge position. But there is no guarantee against a bridge with a priority of 0 and a lower MAC address.
The root guard feature provides a way to enforce the root bridge placement in the network.
The root guard ensures that the port on which root guard is enabled is the designated port. Normally, root bridge ports are all designated ports, unless two or more ports of the root bridge are connected together. If the bridge receives superior STP Bridge Protocol Data Units (BPDUs) on a root guard-enabled port, root guard moves this port to a root-inconsistent STP state. This root-inconsistent state is effectively equal to a listening state. No traffic is forwarded across this port. In this way, the root guard enforces the position of the root bridge.
The example in this section demonstrates how a rogue root bridge can cause problems on the network and how root guard can help.
In Figure 1, Switches A and B comprise the core of the network, and A is the root bridge for a VLAN. Switch C is an access layer switch. The link between B and C is blocking on the C side. The arrows show the flow of STP BPDUs.
In Figure 2, device D begins to participate in STP. For example, software-based bridge applications are launched on PCs or other switches that a customer connects to a service-provider network. If the priority of bridge D is 0 or any value lower than the priority of the root bridge, device D is elected as a root bridge for this VLAN. If the link between device A and B is 1 gigabit and links between A and C as well as B and C are 100 Mbps, the election of D as root causes the Gigabit Ethernet link that connects the two core switches to block. This block causes all the data in that VLAN to flow via a 100-Mbps link across the access layer. If more data flow via the core in that VLAN than this link can accommodate, the drop of some frames occurs. The frame drop leads to a performance loss or a connectivity outage.
The root guard feature protects the network against such issues.
The configuration of root guard is on a per-port basis. Root guard does not allow the port to become an STP root port, so the port is always STP-designated. If a better BPDU arrives on this port, root guard does not take the BPDU into account and elect a new STP root. Instead, root guard puts the port into the root-inconsistent STP state. You must enable root guard on all ports where the root bridge should not appear. In a way, you can configure a perimeter around the part of the network where the STP root is able to be located.
In Figure 2, enable root guard on the Switch C port that connects to Switch D.
Switch C in Figure 2 blocks the port that connects to Switch D, after the switch receives a superior BPDU. Root guard puts the port in the root-inconsistent STP state. No traffic passes through the port in this state. After device D ceases to send superior BPDUs, the port is unblocked again. Via STP, the port goes from the listening state to the learning state, and eventually transitions to the forwarding state. Recovery is automatic; no human intervention is necessary.
This message appears after root guard blocks a port:
Availability
Root guard is available in Catalyst OS (CatOS) for Catalyst 29xx, 4500/4000, 5500/5000, and 6500/6000 in software version 6.1.1 and later. For the Catalyst 6500/6000 that runs Cisco IOS® system software, this feature was first introduced in Cisco IOS Software Release 12.0(7)XE. For the Catalyst 4500/4000 that runs Cisco IOS system software, this feature is available in all releases.
For the Catalyst 2900XL and 3500XL switches, root guard is available in Cisco IOS Software Release 12.0(5)XU and later. The Catalyst 2950 series switches support the root guard feature in Cisco IOS Software Release 12.0(5.2)WC(1) and later. The Catalyst 3550 series switches support the root guard feature in Cisco IOS Software Release 12.1(4)EA1 and later.
Configuration
CatOS Configuration
The root guard configuration is on a per-port basis. On Catalyst switches that run CatOS, configure root guard in this way:
In order to verify whether the root guard is configured, issue this command:
Cisco IOS Software Configuration for Catalyst 6500/6000 and Catalyst 4500/4000
On the Catalyst 6500/6000 or Catalyst 4500/4000 switches that run Cisco IOS system software, issue this set of commands in order to configure STP root guard:
Note: Cisco IOS Software Release 12.1(3a)E3 for the Catalyst 6500/6000 that runs Cisco IOS system software changed this command from spanning-tree rootguard to spanning-tree guard root. The Catalyst 4500/4000 that runs Cisco IOS system software uses the spanning-tree guard root command in all releases.
Cisco IOS Software Configuration for Catalyst 2900XL/3500XL, 2950, and 3550
On the Catalyst 2900XL, 3500XL, 2950, and 3550, configure switches with root guard in interface configuration mode, as this example shows:
What Is the Difference Between STP BPDU Guard and STP Root Guard?
BPDU guard and root guard are similar, but their impact is different. BPDU guard disables the port upon BPDU reception if PortFast is enabled on the port. The disablement effectively denies devices behind such ports from participation in STP. You must manually reenable the port that is put into errdisable state or configure errdisable-timeout.
Root guard allows the device to participate in STP as long as the device does not try to become the root. If root guard blocks the port, subsequent recovery is automatic. Recovery occurs as soon as the offending device ceases to send superior BPDUs.
For more information about BPDU guard, refer to this document:
Does the Root Guard Help with the Two Roots Problem?
There can be a unidirectional link failure between two bridges in a network. Because of the failure, one bridge does not receive the BPDUs from the root bridge. With such a failure, the root switch receives frames that other switches send, but the other switches do not receive the BPDUs that the root switch sends. This can lead to an STP loop. Because the other switches do not receive any BPDUs from the root, these switches believe that they are the root and start to send BPDUs.
When the real root bridge starts to receive BPDUs, the root discards the BPDUs because they are not superior. The root bridge does not change. Therefore, root guard does not help to resolve this issue. The UniDirectional Link Detection (UDLD) and loop guard features address this issue.
For more information on STP failure scenarios and how to troubleshoot them, refer to this document:
Усиление протокола STP с помощью функций защиты от петель и обнаружения отклонений BPDU
Параметры загрузки
Содержание
Введение
Протокол STP разрешает физически избыточные топологии в древовидные топологии без петель. Самая большая проблема протокола STP заключается в том, что некоторые отказы оборудования могут вызывать сбой этого протокола. Такой сбой приводит к образованию петель пересылки (или петель STP). Петли STP вызывают серьезные перебои в работе сети.
В данном документе описана функция защиты от петель STP, предназначенная для повышения стабильности сетей уровня 2 (L2). Здесь также описывается функция обнаружения потери BPDU. Функция обнаружения потери BPDU представляет собой средство диагностики, которое создает сообщения системного журнала, если пакеты BPDU не получены в надлежащий срок.
Предварительные условия
Требования
В данном документе предполагается, что читатель знаком с принципами работы протокола STP. С принципами работы протокола STP можно ознакомиться в документе Общее описание протокола STP и его настройка на коммутаторах Catalyst.
Используемые компоненты
Содержимое данного документа не ограничивается определенными версиями оборудования и программного обеспечения.
Условные обозначения
Доступность функций
Функция защиты от петель STP была впервые реализована в CatOS версии 6.2.1 программы Catalyst для платформ Catalyst 4000 и Catalyst 5000 и в версии 6.2.2 для платформы Catalyst 6000.
Функция обнаружения потери BPDU впервые реализована в CatOS версии 6.2.1 программы Catalyst для платформ Catalyst 4000 и Catalyst 5000 и в версии 6.2.2 для платформы Catalyst 6000.
Функция защиты от петель STP впервые реализована в ПО Cisco IOS выпуска 12.1(12c)EW для коммутаторов Catalyst 4500 и в ПО Cisco IOS выпуска 12.1(11b)EX для Catalyst 6500.
Функция обнаружения потери BPDU не поддерживается коммутаторами Catalyst с системным ПО Cisco IOS.
Краткое описание ролей портов протокола STP
Для внутренних целей протокол STP каждому порту моста (или коммутатора) назначает роль на основе конфигурации, топологии, относительного положения порта в топологии и других факторов. Роль порта определяет поведение порта с точки зрения протокола STP. В зависимости от назначенной роли порт либо отправляет, либо принимает пакеты BPDU протокола STP и пересылает или блокирует трафик данных. В следующем списке приведено краткое описание каждой роли порта STP.
Назначенный. Для каждого соединения (сегмента) выбирается один назначенный порт. Назначенный порт — это порт, ближайший к корневому мосту. Этот порт отправляет пакеты BPDU по этому соединению (сегменту) и пересылает трафик на корневой мост. В сети с топологией сходимости STP все назначенные порты находятся в состоянии пересылки STP.
Корневой. У моста может быть только один корневой порт. Корневой порт — это порт, ведущий к корневому мосту. В сети с топологией сходимости STP корневой порт находится в состоянии пересылки STP.
Альтернативный. Альтернативные порты ведут к корневому мосту, но не являются корневыми портами. Альтернативные порты поддерживают состояние блокировки STP.
Резервный. Это особый случай, когда два или более портов одного моста (коммутатора) связаны между собой напрямую или через общий носитель. В этом случае один порт является назначенным, а остальные порты блокируются. Такой порт имеет роль резервного.
Защита от петель STP
Описание функции
Функция защиты от петель STP обеспечивает дополнительную защиту от петель пересылки на уровне 2 (петель STP). Петля STP образуется, когда заблокированный порт STP в избыточной топологии ошибочно переходит в состояние пересылки. Обычно причина этого в том, что один из портов физически избыточной топологии (не обязательно заблокированный порт STP) перестает получать пакеты BPDU протокола STP. Работа протокола STP зависит от непрерывного приема и передачи пакетов BPDU на основе роли порта. Назначенный порт передает пакеты BPDU, а неназначенный порт получает пакеты BPDU.
Когда один из портов в физически избыточной топологии перестает принимать пакеты BPDU, протокол STP считает такую топологию как топологию без петель. В итоге заблокированный порт из альтернативного или резервного порта превращается в назначенный и переходит в состояние пересылки. В такой ситуации образуется петля.
Функция защиты от петель выполняет дополнительные проверки. Если пакеты BPDU больше не принимаются неназначенным портом, а защита от петель включена, то такой порт переводится в состояние блокировки вследствие возможности петли STP, а не в состояние прослушивания, самообучения (learning) или пересылки. Без функции защиты от петель порт принимает роль назначенного порта. Порт переходит в состояние пересылки STP и формирует петлю.
Когда защита от петель блокирует несогласованный порт, в журнале регистрируется следующее сообщение:
Когда пакет BPDU принимается портом в состоянии блокировки вследствие возможности петли STP, этот порт переходит в другое состояние STP. Согласно полученному блоку BPDU это значит, что восстановление выполнено автоматически и вмешательство не требуется. После восстановления в журнале регистрируется следующее сообщение:
Чтобы проиллюстрировать это поведение, рассмотрим следующий пример.
Коммутатор A является корневым коммутатором. Коммутатор C не получает пакеты BPDU от коммутатора B из-за сбоя однонаправленного соединения между коммутатором B и коммутатором C.
Без защиты от петель заблокированный порт STP на коммутаторе C переходит в состояние прослушивания STP по истечении времени, задаваемого таймером max_age, а затем переходит в состояние пересылки через промежуток, равный удвоенному значению forward_delay. В такой ситуации образуется петля.
Когда функция защиты от петель включена, после обнуления таймера max_age заблокированный порт на коммутаторе C переходит в состояние блокировки вследствие возможности петли STP. Порт в состоянии блокировки вследствие возможности петли STP не предает пользовательский трафик, поэтому петля не образуется. (Состояние блокировки вследствие возможности петли фактически эквивалентно состоянию блокировки.)
Замечания по настройке
Функция защиты от петель включается для каждого порта отдельно. Однако поскольку функция защиты от петель блокирует порт на уровне STP, она блокирует несогласованные порты для каждой VLAN по отдельности (поскольку протокол STP настроен отдельно для каждой VLAN). Значит, если пакеты BPDU не принимаются на магистральном порту только одной отдельной VLAN, то блокируется только эта VLAN (переводится в состояние блокировки вследствие возможности петли STP). По этой же причине, если эта функция включена в интерфейсе EtherChannel, блокируется весь канал отдельной VLAN, а не только одно соединение (так как EtherChannel с точки зрения протокола STP является одним логическим портом).
На каких портах должна быть включена защита от петель? Наиболее очевидный ответ: на заблокированных портах. Однако это не совсем верно. Защита от петель должна быть включена на неназначенных портах (точнее, на корневых и альтернативных портах) для всех возможных комбинаций активных топологий. Поскольку защита от петель не устанавливается для каждой VLAN по отдельности, один и тот же (магистральный) порт может быть назначенным в одной сети VLAN (VLAN) и неназначенным в другой. Следует также учитывать возможные сценарии перехода на другой ресурс при сбое.
Рассмотрим следующий пример.
По умолчанию защита от петель отключена. Для включения защиты от петель используется следующая команда:
Начиная с версии 7.1(1) ПО Catalyst (CatOS), защита от петель может включаться глобально на всех портах. Фактически защита от петель включается на всех соединениях «точка-точка». Соединение «точка-точка» определяется по состоянию дуплексной передачи соединения. Если настроен полнодуплексный режим, соединение считается соединением «точка-точка». Еще можно настроить или переопределить глобальные настройки для каждого порта по отдельности.
Чтобы включить защиту от петель глобально, выполните следующую команду:
Чтобы отключить защиту от петель, выполните следующую команду:
Чтобы отключить защиту от петель глобально, выполните следующую команду:
Чтобы проверить состояние защиты от петель, выполните следующую команду:
Сравнение функций защиты от петель и UDLD
Защита от петель и UDLD (обнаружение однонаправленной связи) функционально пересекаются, частично из-за того, что обе эти функции защищают от сбоев протокола STP, вызванных однонаправленными соединениями. Однако эти функции различаются как функционально, так и по способу решения этой проблемы. В следующей таблице описываются функциональные возможности защиты от петель и UDLD:
Возможность настройки действий
Да, с функцией тайм-аута состояния «err-disable»
Защита от сбоев STP, вызванных однонаправленными соединениями
Да, когда включена на всех корневых и альтернативных портах в избыточной топологии
Да, когда включена для всех соединений в избыточной топологии
Защита от сбоев STP, вызванных проблемами ПО (выделенный коммутатор не отправляет блоки BPDU)
Защита от неправильных кабельных соединений.
В зависимости от конкретных особенностей проекта можно выбрать функцию UDLD или защиту от петель. В отношении протокола STP наиболее заметное различие между этими двумя функциями заключается в отсутствии у UDLD защиты от сбоев STP, вызванных проблемами ПО. В результате выделенный коммутатор не отправляет пакеты BPDU. Однако сбои такого типа происходят (в десятки раз) реже, чем сбои, вызванные однонаправленными соединениями. В свою очередь, функция UDLD может быть более гибкой в случае однонаправленных соединений в EtherChannel. В этом случае UDLD отключает только неисправные соединения, а канал сохраняет работоспособность за счет оставшихся соединений. При таком сбое защита от петель переводит порт в состоянии блокировки вследствие возможности петли, чтобы блокировать весь канал.
Кроме того, защита от петель не действует на совместно используемых соединениях и в ситуациях, когда с момента соединения соединение является однонаправленным. В последнем случае порт никогда не получает блоки BPDU и становится назначенным. Так как такое поведение может быть нормальным, этот случай не охватывается защитой от петель. Защиту от такого сценария предоставляет UDLD.
Как уже отмечено, самый высокий уровень защиты обеспечивается, когда включены функции UDLD и защиты от петель.
Взаимодействие защиты от петель с другими функциями STP
Защита корня дерева STP
Функции защиты корня дерева STP и защиты от петель являются взаимоисключающими. Защита корня дерева STP используется на назначенных портах и не разрешает порту изменять состояние. Защита от петель действует на неназначенных портах и разрешает порту становиться назначенным по истечении срока max_age. Защиту корня дерева STP нельзя включить для порта, на котором включена защита от петель. Когда для порта включается защита от петель, она отключает настроенную на этом порте защиту корня дерева STP.
Функции uplink fast и backbone fast
Функции uplink fast и backbone fast прозрачны для защиты от петель. Когда во время повторной конвергенции функция backbone fast пропускает max_age, это не вызывает срабатывание защиты от петель. Дополнительные сведения о функциях uplink fast и backbone fast см. в следующих документах:
PortFast и защита BPDU и динамическая виртуальная ЛС
Защиту от петель нельзя включить для портов, на которых включена функция PortFast. Так как защита BPDU действует на портах с включенной функцией portfast, к защите BPDU применяются некоторые ограничения. Защиту от петель нельзя включить на портах динамической виртуальной сети, так как на таких портах уже включена функция portfast.
Совместно используемые соединения
Защиту от петель не следует включать на совместно используемых соединениях. Если защиту от петель включить на совместно используемых соединениях, то трафик от узлов, подключенных к общим сегментам, может блокироваться.
Множественные связующие деревья (MST)
Защита от петель правильно функционирует в среде MST.
Обнаружение потери BPDU
Функция защиты от петель должна правильно взаимодействовать с функцией обнаружения потери BPDU.
Обнаружение потери BPDU
Описание функции
Работа протокола STP сильно зависит от своевременного получение пакетов BPDU. При каждом сообщении hello_time message (по умолчанию каждые 2 секунды) корневой мост отправляет пакеты BPDU. Некорневые мосты не создают пакеты BPDU заново для каждого сообщения hello_time, а принимают пакеты BPDU, ретранслированные от корневого моста. Поэтому каждый некорневой мост должен получать пакеты BPDU в каждой VLAN для каждого сообщения hello_time. В некоторых случаях пакеты BPDU теряются или ЦП моста слишком занят, чтобы своевременно ретранслировать пакеты BPDU. Такие или другие проблемы могут вызвать запаздывание пакетов BPDU (если они вообще получаются). Эта проблема может нарушить стабильность топологии STP.
Обнаружение потери BPDU позволяет коммутатору отслеживать запаздывающие пакеты BPDU и уведомлять администратора с помощью сообщений системного журнала. Для каждого порта, для которого когда-либо было зафиксировано запаздывание (или искажение) пакета BPDU, функция обнаружения задержки сообщит о самой последней задержке с указанием ее длительности. Она также указывает максимальную длительность задержки блока BPDU для этого конкретного порта.
Чтобы защитить ЦП моста от перегрузки, сообщение системного журнала создается не при каждой задержке пакета BPDU. Частота создания сообщений ограничивается одним сообщением каждые 60 секунд. Однако если задержка BPDU превышает значение max_age, деленное на 2 (что по умолчанию равно 10 с), сообщение печатается немедленно.
Примечание: Обнаружения потери BPDU — это функция диагностики. При обнаружении задержки пакетов BPDU она отправляет сообщение системного журнала. Функция обнаружения потери BPDU не выполняет никаких других корректирующих действий.
Пример сообщения системного журнала, созданного функцией обнаружения потери BPDU:
Замечания по настройке
Обнаружение потери BPDU настраивается для каждого коммутатора по отдельности. По умолчанию эта функция отключена. Чтобы включить обнаружение потери BPDU, выполните следующую команду:
Чтобы просмотреть сведения об обнаружении задержки пакетов BPDU, воспользуйтесь командой show spantree bpdu-skewing | как показано в следующем примере: