Spanning Tree на пальцах. Зачем Cisco блокирует исправный порт

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

В правильно настроенной сети второй кабель сам по себе не должен устроить аварию. Коммутаторы Cisco используют Spanning Tree Protocol, или STP, чтобы обнаруживать избыточные пути и оставлять часть из них в резерве. Именно поэтому администратор иногда видит совершенно исправный порт со статусом BLK. Разберемся, откуда он взялся и почему попытка исправить ситуацию отключением STP может закончиться гораздо хуже.

Что такое петля в сети и как ее распознать

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

Теперь соединим два коммутатора двумя независимыми кабелями. Если оба соединения одновременно пересылают обычный трафик, появляется замкнутый путь. Кадр, отправленный через один линк, может вернуться через второй и снова попасть в сеть.

На третьем, сетевом, уровне у IP-пакетов есть поле TTL, значение которого уменьшается на каждом маршрутизаторе. У обычного Ethernet-кадра такого механизма нет, и кадры в петле могут циркулировать бесконечно. В итоге возникает широковещательный шторм, а устройства в затронутой VLAN начинают работать с серьезными сбоями.

Одновременно коммутаторы видят один и тот же MAC-адрес то на одном порту, то на другом. Таблица MAC-адресов постоянно переписывается. Cisco называет такое поведение MAC flapping. В журнале Catalyst при подобной ситуации можно встретить сообщение вида:

%SW_MATM-4-MACFLAP_NOTIF: Host xxxx.xxxx.xxxx in vlan X is flapping between port Gi1/0/1 and port Gi1/0/2

Типичные признаки петли довольно заметны: резко растет трафик на интерфейсах, увеличивается загрузка оборудования, появляются сообщения о перемещении MAC-адресов, а связь внутри VLAN становится нестабильной. Подозрительный порт выдает аномально высокий input rate в выводе show interfaces | include is up|input rate. Само сообщение MACFLAP бывает и безобидным, например, при роуминге Wi-Fi-клиентов.

Если нужны два одновременно работающих соединения между одними и теми же устройствами, их объединяют в EtherChannel, например, с помощью LACP.

Почему порт Cisco в состоянии BLK

Spanning Tree Protocol строит из физической сети логическое дерево без замкнутых путей. Кабели при этом остаются подключенными. STP просто определяет, какие порты могут пересылать обычные кадры, а какие должны временно оставаться резервными.

Для этого коммутаторы обмениваются служебными сообщениями BPDU, Bridge Protocol Data Units. В них передается информация, необходимая для выбора корневого коммутатора и расчета путей.

Сначала выбирается корневой мост, root bridge. Им становится устройство с наименьшим идентификатором моста, Bridge ID. Он состоит из приоритета и MAC-адреса: приоритет сравнивают первым, а при равенстве – MAC.

Затем остальные устройства ищут лучший путь к корневому мосту. STP складывает стоимости портов на пути до корня, а стоимость порта зависит от скорости. На Catalyst 9300 порт на 1 Гбит/с по умолчанию стоит 20000, у старых Catalyst вроде 2960-X – всего 4. Порт с лучшим путем к корню становится корневым портом, root port.

На каждом сегменте также выбирается назначенный порт, designated port, который пересылает трафик в сторону этого сегмента.

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

Посмотреть, что происходит на Cisco, можно командой:

show spanning-tree

Для конкретной VLAN:

show spanning-tree vlan 10

Современный Catalyst может вывести примерно такую таблицу:

Interface        Role Sts Cost      Prio.Nbr Type
 ---------------- ---- --- --------- -------- ----------------
 Gi1/0/1          Root FWD 20000     128.1    P2p
 Gi1/0/2          Altn BLK 20000     128.2    P2p

Root FWD означает, что первый интерфейс выбран корневым и пересылает кадры. Altn BLK у второго говорит о резервной роли. Физическая неисправность из этого вывода не следует. В терминах RSTP такой порт находится в состоянии discarding, но Cisco показывает его как BLK, отсюда и привычное выражение blocked port.

Снимать такую блокировку командой no spanning-tree vlan 10 нельзя: резервный кабель замкнет петлю, и оба линка начнут пересылать кадры.

Чем STP отличается от RSTP и Rapid PVST+

Классический STP основан на стандарте IEEE 802.1D. При изменении топологии ему требуется время, чтобы безопасно перевести порт в рабочее состояние: по 15 секунд на listening и learning и до 20 секунд ожидания max age, то есть 30–50 секунд. В традиционном описании используются состояния blocking, listening, learning и forwarding.

RSTP, Rapid Spanning Tree Protocol, появился как развитие STP и описан в стандарте IEEE 802.1w. Его главная задача – быстрее перестраивать дерево: на линках point-to-point порт переходит в forwarding без ожидания таймеров. Для резервных путей введены отдельные роли alternate и backup, а состояния disabled, blocking и listening объединены в discarding. Learning и forwarding остались.

У Cisco есть собственная реализация Rapid PVST+, где для каждой VLAN может работать отдельный экземпляр быстрого Spanning Tree. В актуальной документации Catalyst 9300 с IOS XE 26.x Rapid PVST+ указан как режим по умолчанию. На других сериях и в старых версиях ПО настройки могут отличаться, поэтому реальный режим лучше проверить на самом коммутаторе:

show spanning-tree summary

В выводе можно увидеть, например:

Switch is in rapid-pvst mode

Менять режим STP посреди рабочего дня не стоит. Команда

spanning-tree mode rapid-pvst

действительно включает Rapid PVST+ на поддерживаемых устройствах, однако смена режима останавливает все экземпляры Spanning Tree и может прервать трафик.

Как назначить root bridge на Cisco

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

Корневой коммутатор лучше размещать на уровне ядра или распределения, а не на уровне доступа.

В начале вывода show spanning-tree vlan 10 будут секции Root ID и Bridge ID. Если текущий коммутатор сам является корневым, Cisco выводит:

This bridge is the root

На Catalyst с PVST+ или Rapid PVST+ назначить предпочтительный корневой коммутатор для VLAN можно командой:

configure terminal
 spanning-tree vlan 10 root primary

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

spanning-tree vlan 10 root secondary

Первая команда задает приоритет 24576, а если этого недостаточно – на 4096 ниже, чем у текущего корня. Вторая задает 28672. Обе команды срабатывают однократно и сохраняются в конфигурации как обычная настройка priority. Перед настройкой нескольких VLAN нужно разобраться с общей топологией: у каждой VLAN в PVST+ или Rapid PVST+ может быть свое дерево и свой root bridge.

Как настроить PortFast и BPDU Guard

Обычному компьютеру, принтеру или серверу не нужно участвовать в построении дерева между коммутаторами. Для таких конечных устройств у Cisco есть PortFast. Он позволяет порту сразу перейти к пересылке трафика после поднятия линка, пропуская состояния listening и learning.

На обычном access-порту PortFast можно включить так:

configure terminal
 interface GigabitEthernet1/0/10
 spanning-tree portfast

Включать PortFast на порту, к которому подключен коммутатор или хаб, нельзя: STP может не заметить петлю. Для транкового порта к серверу или гипервизору вместо этой команды нужна spanning-tree portfast trunk.

PortFast сам по себе не означает полного отключения Spanning Tree: получив BPDU, порт теряет этот статус и работает как обычный порт STP. Но если пользователь подключит к розетке еще один коммутатор, порт к этому моменту уже будет пересылать трафик. Поэтому PortFast обычно дополняют BPDU Guard.

На том же интерфейсе защита включается командой:

spanning-tree bpduguard enable

Для всех access-портов сразу есть глобальные команды spanning-tree portfast default и spanning-tree portfast bpduguard default.

Если такой порт получает BPDU, BPDU Guard считает ситуацию ошибочной и переводит интерфейс в состояние err-disabled. Это останавливает потенциально опасное соединение до того, как оно успеет изменить топологию сети.

Типичный случай выглядит так. В переговорной есть настенная розетка, рассчитанная на ноутбук. На порту коммутатора включены PortFast и BPDU Guard. Пользователь приносит маленький коммутатор и подключает его к этой розетке. Если это управляемый коммутатор, он сам отправит BPDU. Если же простой неуправляемый коммутатор включили сразу в две розетки, Catalyst получит обратно свои же BPDU. В обоих случаях Catalyst отключит конкретный порт. В результате связь пропадает только в одной розетке, а не во всей VLAN.

Найти такие порты поможет команда show interfaces status err-disabled. После устранения причины интерфейс, отключенный функцией BPDU Guard, при стандартной ручной схеме можно вернуть в работу:

configure terminal
 interface GigabitEthernet1/0/10
 shutdown
 no shutdown

Есть и автоматическое восстановление из err-disabled – по умолчанию порт поднимается через 300 секунд:

errdisable recovery cause bpduguard

Проверить настройку можно командой:

show errdisable recovery

Автоматическое восстановление имеет смысл только там, где администратор понимает причину срабатывания. Если петля физически осталась, периодическое включение порта будет снова и снова создавать проблему.

Еще одна функция, BPDU Filter, устроена иначе. Команда spanning-tree bpdufilter enable на интерфейсе прекращает передачу и прием BPDU, то есть по сути отключает STP на этом порту. Использовать BPDU Filter как способ убрать мешающие BPDU на обычном межкоммутаторном соединении нельзя.